New 200D Orion Protocol 2 Firmware Topic

FIRMWARE TOPICS ONLY--non-firmware topics will be MOVED
Forum rules
Until such time as the New Protocol firmware goes into general release, all discussion will be concentrated here.
User avatar
w-u-2-o
Posts: 2270
Joined: Fri Mar 10, 2017 1:47 pm

New 200D Orion Protocol 2 Firmware Topic

Postby w-u-2-o » Mon Feb 10, 2020 3:21 pm

UPDATE 1.9_pre4 10 Feb 2020

Additional bug fixes including transverter operation, PTT fixes and timing adjustments.

Metis_Orion_NP_v1.9_pre4.rbf
(1.65 MiB) Downloaded 114 times


Previous updates here:

https://github.com/TAPR/OpenHPSDR-Firmware/tree/master/Protocol%202/Orion%20(ANAN-200D)
User avatar
W1AEX
Posts: 300
Joined: Sun Apr 09, 2017 6:17 pm
Location: Connecticut, USA
Contact:

Re: New 200D Orion Protocol 2 Firmware Topic

Postby W1AEX » Wed Feb 12, 2020 5:32 pm

Thank you for the link to the Metis_Orioni_NP-1.9_pre4.rbf version of the protocol 2 firmware. I've pasted in what I see with each version from 1.7 through this new one. For my particular 200D it still looks like version 1.8 works the best from 160 - 6 meters with stable Pure Signal correction once the FPGA warms up. The new version is pretty close but Pure Signal will not correct on 6 meters and it's sketchy from 20m through 10m as well. I do not have a transverter so cannot report on that function.

73, Rob W1AEX
----------------------------------------------------------------------------------------
ANAN 200D Firmware notes:

Firmware 1.7 - Pure Signal corrects when cold but not on upper bands when warmed up. Stuck MIC input gain. SWR not accurate.

Firmware 1.8 - Pure Signal will not correct until the FPGA warms up for around 10 minutes. Works fine on all bands after that.

Firmware 1.8qskdbg1 - Receiver not functional with a loud buzzing noise and large spikes in the panadapter.

Firmware 1.9 pre 2 - Pure Signal corrects immediately but fails to correct after the FPGA warms up.

Firmware 1.9 pre 3 - Pure Signal corrects immediately but fails to correct after the FPGA warms up.

Firmware 1.9 pre 4 - Pure Signal corrects on 160/75 immediately and corrects on 40m after the FPGA warms up. 20m through 10m exhibit pure signal stability issues with a very distorted AmpView display and there is no correction on 6m.
"One thing I am certain of is that there is too much certainty in the world."
User avatar
n1gp
Posts: 68
Joined: Sun Apr 09, 2017 6:34 pm

Re: New 200D Orion Protocol 2 Firmware Topic

Postby n1gp » Thu Feb 13, 2020 12:07 am

Hi Rob,

Tnx for the detailed report.

Is the Firmware 1.8 you report the same as the one available on the TAPR
github protocol2 area?

-Rick / N1GP
User avatar
W1AEX
Posts: 300
Joined: Sun Apr 09, 2017 6:17 pm
Location: Connecticut, USA
Contact:

Re: New 200D Orion Protocol 2 Firmware Topic

Postby W1AEX » Thu Feb 13, 2020 3:46 am

Hi Rick,

Yes, it is the same v1.8 that is available in the TAPR protocol 2 area. Pure Signal is very stable from 160m - 6m once the FPGA warms up (10 minutes for 6 meters, much less for the lower bands) and it runs all day long without any issues.

:)
"One thing I am certain of is that there is too much certainty in the world."
User avatar
W3MMR
Posts: 71
Joined: Thu Jul 11, 2019 8:36 am
Location: Chester, PA
Contact:

Re: New 200D Orion Protocol 2 Firmware Topic

Postby W3MMR » Sat Mar 28, 2020 10:33 am

Just loaded 1.9 onto my 200D as of last night, and its working hi hi fine business OM lol. Pure Signal is working and hanging in there just fine, no glitches or bugs to report as of yet, 5 hours of operation. Will update if I have any issues...


Perry
Studio "A" - Anan 200D, P2 1.9, Thetis 2.6.9c3, Dell XPS 8700 i7-4770k, Samsung EVO 860 SSD, Nvidia GeForce GTX1050ti, 16GB RAM, Shure SM7B, AL80BX
Studio "B" - Heath-Kit DX100, D-104, National NC-303, Hammarlund HQ-140-X
vk1hx
Posts: 47
Joined: Fri Sep 13, 2019 12:03 pm

Re: New 200D Orion Protocol 2 Firmware Topic

Postby vk1hx » Tue May 19, 2020 8:59 am

Is there any future intention to keep developing the ANAN200D P2 firmware? It feels like its being let go and only developed on the MK2 series ANAN's?

Like Rob W1AEX, I am getting by with P2 v1.8 for my 200D Rev.24 and experienced the same issues as Rob when testing the other beta firmware versions. Under P2 v1.8 I am still having to wait for about 20mins before I can use the ANAN on SSB due to previously posted issues.

Is there some way of building into the firmware so sort of log that picks up what the issue are on first startup to be extracted my the developer to individually correct for the "non masses"? Or changing how the ANAN communicates via the network (is protocol) - TCP/Netbios?

Cheers
Phil
User avatar
w-u-2-o
Posts: 2270
Joined: Fri Mar 10, 2017 1:47 pm

Re: New 200D Orion Protocol 2 Firmware Topic

Postby w-u-2-o » Tue May 19, 2020 11:02 am

vk1hx wrote:Is there any future intention to keep developing the ANAN200D P2 firmware? It feels like its being let go and only developed on the MK2 series ANAN's?
That's kind of an unfair statement on several levels. First, you might notice that there has been no further development for some time on the Orion MKII platform, either. It doesn't work perfectly for everyone on that platform, either.

Second, "abandon" is probably not the right word to use. All of the software and firmware for the openHPSDR family of hardware, of which the Apache hardware is simply the most numerous by far, is open source and written by self-selected, volunteer developers because it is personally interesting to them to do so. With respect to the firmware, I believe the total number of people to work on it for all platforms from the Hermes to the Orion MKII has been three. Yes, three, that's it. Because the number of folks who a) have the time, b) the inclination, and c) the skill to do so is a very, VERY small set of people.

At this time every one of those folks has either burned out on the hobby and/or simply got too busy with real life to do any more work. And I say this with the utmost respect and absolutely no negative connotations. It takes a tremendous amount of effort to build firmware, or complex software, and such efforts can only be sustained on a volunteer basis for relatively short periods of time by any one person. This is why development for openHPSDR software and firmware tends to be cyclical. We get someone skilled, who is a ham, and who "gets and itch", so to speak. The occurrence of those "itches" are rare and fleeting because there are so few who are susceptible to them. And they scratch the itch and it eventually goes away. As a result the rest of us poor, unskilled, non-developer types hugely benefit, but then the cycle ends and we have to wait for another one to occur.

Until and unless someone decides to actually fund professional development of the firmware, and the open source license holder (I'm not sure who that is) agrees to a derivative work that someone can charge money for, this is how it is going to remain. Personally, I'd happily pay money to Apache or whoever if they provided a new version of firmware that "just worked". And people have actually dangled money in front of the volunteer developers in a casual way (GoFundMe, that sort of thing), but none of them ever bought into the idea because to them it is a hobby and they did not want to be beholden to anyone or deal with that kind of pressure.
Is there some way of building into the firmware so sort of log that picks up what the issue are on first startup to be extracted my the developer to individually correct for the "non masses"? Or changing how the ANAN communicates via the network (is protocol) - TCP/Netbios?
If our general understanding of the problem is correct, which is that there are problems achieving timing closure on the MAC firmware over temperature and the entire population of hardware, then neither of those methods will work.

73,

Scott
db8gk
Posts: 18
Joined: Thu Apr 02, 2020 8:05 am

Re: New 200D Orion Protocol 2 Firmware Topic

Postby db8gk » Tue May 19, 2020 1:44 pm

Hi,

I'm one of those people with an itch. :) Let's see how long this lasts, but for now I want to contribute to the community.

What I noticed is that there is a certain lack of keeping the zoo of different devices somewhat aligned in terms of development. Source code is not under any sort of version control. Code for different devices is just copied over and then edited separately. There is no automated builds, no automated tests. No bug tracker.

I'm not complaining about this, just noticing areas where I could contribute with my knowledge. I do speak a bit of Verilog, but the mentioned timing issue is one of the tricky ones. Maybe looking at the compiler warnings would get you somewhere, maybe you need a lab with a logic analyzer and an actual device to tackle it.

Now I don't own a 200D. Maybe it would make sense to pool up resources here, to make sure we get enough coverage. I know an OM with a 10 in the city. I have a 7000DLE Mk2. There's probably people here on the forum.

Let's fix this.

73,
Andreas DB8GK
User avatar
w-u-2-o
Posts: 2270
Joined: Fri Mar 10, 2017 1:47 pm

Re: New 200D Orion Protocol 2 Firmware Topic

Postby w-u-2-o » Tue May 19, 2020 6:22 pm

It has been previously suggested that the current Git repo be more fully utilized. And I am on your side with respect to this. However this idea has been, so far, rejected by those who have been contributing.

More specifically, where firmware has been concerned, the very few people who have worked on it (and I'm sure you are familiar with the most recent, and amazing, work by Rick, N1GP) have generally been solo contributors and did not wish to avail themselves of strong configuration management processes, much less anything that would facilitate multiple developers.

Where software is concerned, there certainly has been more opportunity for using cooperative development tools. However, again, those who have worked on the software have explicitly chosen not to avail themselves of those tools. Doug, W5WC, continues to act as the final, human integrator of various branches for PowerSDR and Thetis.

I suggest you start a separate topic in the forum to discuss this issue rather than continue the thread drift here.

As for fixing the timing closure problem, my day job is as a very senior systems engineer who manages the development of systems that are hundreds of times more complex than this one. While Rick has done an amazing job of just guessing at solutions in a brute force way, I believe the correct solution involves ten of each type of SDR board, a high speed logic analyzer, and a thermal chamber. And probably the full version of Quartus, also.

73,

Scott

Return to “Protocol 2 Firmware (all radios)”