New 200D Orion Protocol 2 Firmware Topic

[w-u-2-o]

UPDATE 1.9.15 14 Aug 2021

Numerous bug fixes and timing improvements.
Thetis 2.8.11 build 21f will show the full firmware version number in Setup > General.

Metis_Orion_NP_v1.9.15.rbf

(1.89 MiB) Downloaded 217 times

Quartus project archive file for developers:

Orion_NP_v1.9.15.qar

(231.78 KiB) Downloaded 57 times

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 417 times

Previous updates here:

https://github.com/TAPR/OpenHPSDR-Firmware/tree/master/Protocol%202/Orion%20(ANAN-200D)

[W1AEX]

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.

[n1gp]

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

[W1AEX]

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.

[W3MMR]

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

[vk1hx]

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

[w-u-2-o]

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]

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

[w-u-2-o]

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

[SM7SJR]

Which are the bugs for PTT and transverter operations?
I have 2 x 200D (with 1.8) and I have some strange behavior when using the footswitch to PTT in CW mode and I do use tranverters a lot so I am interested to find out.

Excuse my ignorance but now when Thetis works with protocol 1 what is the main drivers to remain on protocol 2?

73 de SM7SJR, Bjorn

[w-u-2-o]

Which are the bugs for PTT and transverter operations?
I have 2 x 200D (with 1.8) and I have some strange behavior when using the footswitch to PTT in CW mode and I do use tranverters a lot so I am interested to find out.

Are you asking about P2 firmware specifically? If not, then this question does not belong in this topic. In either case I don't remember there being any known bugs.

Excuse my ignorance but now when Thetis works with protocol 1 what is the main drivers to remain on protocol 2?

Because Protocol 2 uses Gigabit Ethernet, Protocol 2 allows for IF sample rates above 384KHz, and it allows for unrestricted use of those sample rates, PureSignal and multiple receivers. Protocol 2 will allow 1536KHz on both RX1 and RX2 and the use of PureSignal under those conditions. Protocol 2 also makes available a "wideband" view of the entire ADC passband.

With Protocol 1 running only at 100Mbit/s you are limited to 192KHz sample rate if using PureSignal, and 384KHz otherwise. If using Thetis and Protocol 1 you are limited to 192KHz all the time because of the fundamental differences in architecture between PowerSDR and Thetis.

Protocol 2 also provides a cleaner and more object oriented firmware interface, but nobody has written any client software that takes advantage of this yet in ways visible to the user.

[vk1hx]

Just wondering if there is anyone who can correct the issue mentioned in P2 Firmware version 1.7? P2 v1.7 works the best for my 200D.

Firmware v1.7 issues: Pure Signal corrects when cold but not on upper bands when warmed up, Stuck MIC input gain, SWR not accurate on transmit.

Not sure if those parts of the firmware can be taken from the P2 Firmware v1.8 and replaced in the v1.7?

Appreciate any assistance.

Regards
Phil - VK1HX

[w-u-2-o]

If you are unable to run 1.8 or 1.9 in your hardware that is most unfortunate, because currently there are no developers interested in or working on either Thetis or the P2 firmware.

[vk1hx]

Well that is most unfortunate. Time to buy a different radio.

Cheers
Phil - VK1HX

[vk1hx]

Hi Rick,

I'm running the 200D updated firmware - Orion_NP_v1.9.15. I have to say so far good results. I can not detect the issues (TX audio and Tune carries) I get with P2 and the ANAN is cold. I was running P2, Orion_NP_v1.8 and had to wait for 30mins or more before I could TX. I was also getting inconsistent Pure Signal correction. Had to keep turning it off and on.

I've tried multiple times rebuilding the DB and my PC system is running Windows 10 Enterprise LTSC which does not have all the bloatware standard.

I'll keep testing and report back later. So far very promising. Thank you again for your efforts and time to support us users. I do appreciate it.

73' Phil - VK1HX

[w-u-2-o]

So did you buy another radio, Phil?

[vk1hx]

So did you buy another radio, Phil?

No Scott, I went back to P1on the 200D and when 2.8.11 came out it was good. This latest development for the 200D from Rick seems good. No adverse effects.

I had a mate of mine test the firmware on his 200D (Rev.16) and he has fluctuating SWR and when he transmits and goes back to RX the RX is attenuated. He has to press the PTT a few time to get the RX floor to come back to normal. Under P1 it all works fine.

Cheers
Phil - VK1HX

[w-u-2-o]

This is great news. I have two other positive reports on the Orion, so that makes 3 positive and one negative.

We need more testers for both Orion and Angelia!

P.S. now I understand why I did not see your other problem as I'm exclusively P2 around here.

[vk1hx]

This is great news. I have two other positive reports on the Orion, so that makes 3 positive and one negative.

We need more testers for both Orion and Angelia!

Its not difficult for me to test firmware releases (P1 or P2) bootloader makes it so simple.

It's almost like you need 2 sets of firmware release for older ANAN's running the different Rev. PA boards, such as Rev.24 and Rev.16. There might be an earlier one, however Rev.16 might suffice?

Can do firmware testing on the 200D if needed. However for my 200D, this latest firmware Orion_NP_v1.9.15 has been great, I've not detected any SEQ errors, TX issue when cold or hot, SWR reading seem normal, TX to RX works fine, no attenuation when returning to RX, PS is stable and works through most bands (can't test 160m - no antenna or 60m - not allocated in VK).

Cheers
Phil - VK1HX

[n1gp]

Hi Phil,

The P1 firmware sent each Alex change twice. The current P2 FW only once.

Maybe there was a bug with the v16 of the Alex PA?

Anyway I made a change to send twice also in this P2 FW.

Could you have your friend try this to see if it doesn't have the PTT issues?:
https://www.dropbox.com/s/tdmkgvnhtany5hk/Orion_NP_v1.9.16.rbf?dl=0

-Rick / N1GP

[W1AEX]

This is great news. I have two other positive reports on the Orion, so that makes 3 positive and one negative.
We need more testers for both Orion and Angelia!

Scott, you can add my cantankerous ANAN 200D to the happy list. Pure Signal engages perfectly from 160-6 meters with no thermal issues from a cold start to fully warmed up. Works fine with 2 RX active all the way up to the 1536k sampling rate on both receivers. Rick has hit a home run with this version!

73, Rob

[vk1hx]

Hi Phil,

The P1 firmware sent each Alex change twice. The current P2 FW only once.

Maybe there was a bug with the v16 of the Alex PA?

Anyway I made a change to send twice also in this P2 FW.

Could you have your friend try this to see if it doesn't have the PTT issues?:
https://www.dropbox.com/s/tdmkgvnhtany5hk/Orion_NP_v1.9.16.rbf?dl=0

-Rick / N1GP

Gawd, I just noticed this reply from you Rick.... LOL

That was super quick. Mate the one you sent me the other night for my 200D has been rock solid so far and working on all variants of Thetis 2.8.11. Top job, however I will try to break it at some point.. hahah.

I will get onto my mate and load the test firmware up and report back soon.

Cheers
Phil - VK1HX

[vk1hx]

Hi Phil,

Could you have your friend try this to see if it doesn't have the PTT issues?:
https://www.dropbox.com/s/tdmkgvnhtany5hk/Orion_NP_v1.9.16.rbf?dl=0

-Rick / N1GP

Hi Rick,

Just finished testing out the P2 firmware Orion_NP_v1.9.16.

The PTT issue (RX attenuation issue) seems to be fixed, didn't occur on several TX tests.

Issue with erratic SWR trips the amp out when using SSB. On a carrier its fine. Maybe a harmonic issue?

PureSignal unstable, corrects sometimes, other times it is hunting for correction.

Cheers

Phil - VK1HX

[G3ZQH]

Hi Rick, another report to help with development

Tried P2 firmware Orion_NP_v1.9.16 on my 200D using Thetis 2.8.11 21f. Looking at PureSignal I see erratic Feedback and Correction which is worse on 17/15/12/10 but gets better (but not completely stable) on 20-160m. I also note a changed two-tone spectrum (on DUP) with a wide band level of background 'noise' as well as the 2 tone signals. My amp cuts out on 10 and 12m when driven by 2-tones, perhaps due to the high background signal? (it works fine just using Tune). So, similar to what Phil has observed.

Using v1.9_pre4 firmware PureSignal was working OK for me on all bands.

73 Dave G3ZQH

[w-u-2-o]

Dave: what revision RF board so you have? And did you try 1.9.15?

[vk1hx]

Hi Dave,

Thanks for your feedback on the Orion_NP_v1.9.16. I have a mate with an older 200D and the P2 firmware I'm using doesnt work to well in his so Rick kindly made some mods. It solved one issue but others still there for now.

Have you tried the new 200D firmware Rick has put together, Metis_Orion_NP_v1.9.15.rbf?

No other P2 firmware was working correctly in my 200D until this recent build. My 200D has a Rev.24 PA board in it so result might not favor the older PA boards Rev.16, 14 etc.

Regards

Phil - VK1HX

[G3ZQH]

Hi
Sorry, typo that should be firmware 1.9.15 and NOT 1.9.16 that I used. I'm using the older Rev 16 PA board in my 200D. PS worked with my previous 1.9 pre4 firmware on all bands but sometimes was slow to 'lock' on to correction but once locked it was stable.
73 Dave G3ZQH

[G3ZQH]

Also, forgot to say that I'll look at 1.9.16 later today and will report back.
73 Dave

[G3ZQH]

PureSignal with recent firmware:
200D rev 16 PA board, Thetis 2.8.11.21f

1.9pre4 - PS works perfectly on all bands 10-160m
1.9.15- Not working at all 10-17m. 20m erratic correction. Amp cuts out on 1-15m, will not apply drive. 160, 80m OK, 60m not
1.9.16- Not working 10-20m. Amp cuts out and will not apply drive 10-17m. 160m, 80m OK, 60m not.

Seems to be a problem with the two-tone spectrum on 1--20m. It is very different with a clean spectrum using 1.9pre4 compared with a very noisy spectrum on 1.9.15 and 1.9.16. I think my amp is cutting out because it is seeing 'out of band' signals.

I hope this helps!

73 Dave G3ZQH

[n1gp]

Hi Dave,

Are you seeing SEQ errors in Thetis using FW 1.9.15 or 1.9.16 ?

-Rick / N1GP