Protocol 2 and hardware inconsistencies

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.
Trucker
Posts: 304
Joined: Wed Nov 03, 2021 5:16 pm

Protocol 2 and hardware inconsistencies

Postby Trucker » Thu Dec 23, 2021 4:12 pm

I hope I am asking this question in the right place.
I am on the verge of purchasing a 7000DLE MKII. My concern is what appears to me to be inconsistent results when installing and running Protocol 2 and Thetis. It seems for some reason, whether a recently manufactured radio or an earlier manufactured radio, that just installing the latest version of Thetis is no guarantee it will work with Protocol 2 and a user may have to resort to installing earlier versions of Thetis to find a version that will work reliability with their particular radio.
I understand it is because of timing issues in the software and the radio's hardware. My question is this, is Apache Labs unable to maintain a consistent level of manufacturing and hardware to the point developers are better able to create software that will work with Protocol 2 without so many problems that I read about here?
What happens if a developer adds a new feature to Thetis but, because of the timing issue, one cannot use it? I fully understand that firmware and software development for the Anan radios is done by volunteers and is open source. And I really like that. But, I can imagine that it could be very frustrating to a developer when some can use their software without issue. And others are getting frustrated and posting questions about why the latest version won't work for them.
Currently, I use a Hermes lite 2 and a Hardrock 50 amplifier to get a feel for how well OpenHPSDR and Thetis work. I really like the software and intend to purchase a 7000DLE MKII soon.
I just want to better understand why the inconsistency in the hardware before I make a purchase.
Merry Christmas
James Whiteway
WD5GWY
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: Protocol 2 and hardware inconsistencies

Postby w-u-2-o » Thu Dec 23, 2021 7:16 pm

James,

Bottom line up front: where the 7000, or any Orion MKII based design, is concerned, your risks are quite low. Most people are very successfully running the latest available version of the firmware, and Thetis, and for the few that experience problems, a slightly older revision of firmware usually does the trick.

In more detail...

Those are legitimate concerns, but you don't quite have the story straight. Some points of clarification:

It's not really a hardware problem. Although there are probably a couple of things that could have been done better, most notably a poor PLL pin choice on the FPGA, the hardware design is not contributing to the problem. And the most recent build of the firmware accounts for the PLL assignment issue.

It's definitely not a software problem. None of this issue has anything whatsoever to do with Thetis. Not that Thetis doesn't have some bugs, or things it could do better, of course.

The problem is wholly associated with achieving reliable timing closure in the firmware design over the entire gamut of hardware serial numbers. This includes the entire gamut of silicon speeds (which vary a little bit even within a given speed grade of FPGA), power supply variations, and thermal conditions (some shacks are hot, some cold, some radios run hard, others easy).

In a normal, commercial firmware development environment this would not be a problem. Full-time, experienced, paid firmware developers would sit in front of a full-fledged, development systems using a paid-for, multi-thousand dollar development software licenses. The hardware manufacturer would have a team of engineers running the firmware through its paces on number of systems that represent fast, slow and middle of the road silicon, low and high voltages, and have them in thermal chambers testing the firmware over a complete range of operating temperatures. This is not the environment that exists.

Instead you have a company that builds hardware, and hardware only, which is Apache. They don't write the firmware. They don't write the software. They do us all a favor by loading some firmware for us before delivery, and they certainly support the developer community very, very well, but that's the extent of what Apache does. (Note: I am not an Apache employee, agent, or any other sort of thing. I just help run this forum). It's also worth mentioning that the hardware is based on an open source hardware license, too, which means that much of what Apache builds has its roots in the amateur, open source hardware development that resulted in the Hermes and its predecessors.

Meanwhile, all of the firmware and software is 100% open source, and 100% developed by volunteers. An extremely small number of volunteers over the years. A damn miniscule number where the firmware is concerned. I believe that from the Hermes forward, no more than 4 or 5 people have ever contributed to the firmware development.

During the development and evolution of Protocol 1 firmware, the fastest clock in the code was 122.8MHz (the sample clock). This is not terribly fast and timing closure was relatively easy. However, P2 firmware involves Gigabit Ethernet, with clock rates in the MAC and PHY interface firmware code ten times that found in P1. This is where the root of the problem lies, i.e. achieving reliable timing closure build-to-build, and across the entire gamut of operating conditions, on this interface.

It has been very difficult to achieve good performance in this environment. We are blessed beyond measure by the developers that have stepped up to the plate, but firmware development is not necessarily their day job. And there has been an unwavering philosophy of having the firmware be 100% open source. This means that a lot of the standard Ethernet logic was home grown, or taken from open source libraries that may not have the same robustness as a non-open-source library. And, finally, they have all chosen to use the highly limited, free version of the Quartus development environment. The free version does not include many important tools and capabilities that aid the developer in achieving reliable timing closure, particularly from build-to-build. At one time there was an initiative to buy the developers a full seat of Quartus, but that idea was rejected philosophically, the argument being that the result really wasn't open source if it required a hobbyist to spend thousands to buy the tools necessary to build the code successfully.

The last person to work on P2, Rick, N1GP, was able to work some miracles (IMHO) where the free version of Quartus was concerned. And he fixed a number of long standing bugs, as well. In general what he has achieved works very well for 90% of of Orion MKII boards, probably 80% of Orion boards, and maybe 70% of Angelia boards (those numbers being my wild ass guestimates based on anecdotal reports). That isn't bad at all considering the open source nature of the radio. And for the few that have issues, probably better than half of those do find a version of P2 that works for them.

It's sometimes a labor of love to get our radios working in a stable and reliable fashion, but considering that they do many things no other radio on the planet can do, most of us feel it's worth the effort.

73,

Scott
K8EZB
Posts: 78
Joined: Sat Oct 23, 2021 3:45 pm

Re: Protocol 2 and hardware inconsistencies

Postby K8EZB » Thu Dec 23, 2021 7:49 pm

I am a newbie to Apache Labs radios, having received a 7000DLE on Dec 14. I have had NO significant issues in getting this running without apparent problems and with excellent reports from my QSOs to date. Based on advice here I quickly updated to the latest Betas of Thetis (2.8.11 21k7) and P2 (2.1.18). These upates went smoothly without drama. Prior to purchasing the radio I spent quite a bit of time reading AL Community posts and became a bit concerned about what I migfht be getting into. So far, pleasantly surprised with the ease with which the radio was made useable. This is not to say that there will not be problems ahead or that one wont have problems with another specific radio serial number. If my experience is representative of radios currently being shipped and the latest Betas of software and firmware, you are very likley to be pleased with your purchase.

Rick
K8EZB
Trucker
Posts: 304
Joined: Wed Nov 03, 2021 5:16 pm

Re: Protocol 2 and hardware inconsistencies

Postby Trucker » Thu Dec 23, 2021 9:15 pm

Scott,
Thank you for the detailed reply. I really do appreciate it. It helps me better understand the overall situation with the Apache labs radios and the development community that has supported them. From my experience with the Hermes Lite 2 and the Hardrock 50 combo, I really want to go forward with purchasing a 7000DLE MKII.
I have been greatly impressed with the performance of that setup and Thetis. I also own a Flex 6600M which I really like. But, the basic features like Noise Reduction and Automatic Notch Filter are far behind what the HL2 and it's DSP processing in Thetis are capable of. Those two things are a big part of why I want to purchase a 7000DLE MKII. I now live in an area with more local noise that the Flex and SmartSDR struggles with and yet Thetis and the HL2 handle it with ease.
Recently, I had an interesting qso with a ham using a 7000DLE ( Blue ). He commented on my audio from my HL2 setup. ( I use a cheap....$20 USB condenser microphone ) His said I could easily use the HL2 and HR50, and get just as good results as I would if I were to move to a 7000DLE MKII. Which to a point is true. Not a huge difference between 50 watts and watts.
But, one thing I think would be of benefit is the second receiver and antenna for beam steering and noise reduction.

Rick,
Thank you for your reply too. It helps knowing that I am not the only one who has felt the way I do about making the move to a 7000DLE MKII.
James
WD5GWY

Return to “Protocol 2 Firmware (all radios)”