No ETA that I'm aware of. Thetis itself is in very, very good shape. It's the Protocol 2 firmware that is struggling to make timing across the entire population of radio hardware (i.e. it exhibits different problems on different radios of the same model number, etc.)

The firmware, which has been suffering from some fairly significant timing closure problems, and which has remained essentially untouched for the last two months due to various distractions such as Hermes II and Minerva (DFC), has only very recently been subject to a new approach to timing closure by Phil, but Phil has not publicly released those efforts yet, and non-publicly they are only available for the 100D right now. It is hoped that we will see a non-public release of the new firmware build on the 200D/8000 soon. If all of that survives contact with a larger test population, then it may be publicly released, perhaps in another month or so.

I'm asking about every 2 months about updates, we are now over 6 months since my first inquiry. The 7000 has been released so do we have any kind of timeline or even info on the progress of fixing the timing issues in the firmware ? Has any work been going on with the Thetis software?

It is looking a lot less likely to me, given the amount of time that has passed with no progress reported and no evidence that it is being worked on, that we will ever see Thetis fully operational. Perhaps it is not possible to solve the timing closure issues with the current FPGA design.

I assume this also means Simon's software won't be available for the Apache Labs radios either as it only runs on protocol 2. I was really looking forward to using it!

I would think this would be very troubling to Apache Labs. Perhaps they should look into investing in firmware development for their radios if they want to continue selling them in the future. Otherwise, they are going to be saddled with a "Model T" while others market SDR's with fancy new features.

Protocol one works quite well but it has serious limitations running at 100 base T for very much future enhancement.

Timing closure on the P2 firmware continues to be an issue. Current focus is on the potential for floor-planning and incremental builds (e.g. locking down each timing critical piece and not allowing it to be rebuilt during subsequent builds) to solve the problem. However, there is a stumbling block here in that only the non-free Altera design tools include such capabilities (as well as a much more sophisticated build engine).

Traditionally the openHPSDR firmware has not only been open source, but also has been developed using the free Altera design tools, thereby allowing anyone who wanted to contribute, derive or simply experiment to do so at effectively zero capital cost. Moving off of this zero cost model represents a powerful philosophical conundrum for the openHPSDR firmware development community. Doing so does not necessarily make the code any less open source, but it does raise the bar extremely high for anyone who cannot afford the rather expensive development tools to contribute, derive or experiment with/from the open source firmware codebase.

Please do not start making offers of money for development tools. That is not the core issue at this time. It requires resolution of the philosophical ramifications of moving away from free tools to tools that cost on the order of $4K/seat. Whether that is privately or publicly funded, certainly the pure cost issue can be solved for the current development team. The core issue remains the fact that if such funding does happen, who will fund the next person who wants a seat "just to play around with the code". The latter will effectively become forever out of reach.

FWIW, my personal opinion is that moving to the more sophisticated development environment will solve the problem handily. And, at the current level of code speed and complexity, is an absolute requirement for success. Just the GigE MAC alone, running at gigabit speeds, represents a significant challenge to get correct otherwise. I don't see any choice if the current technology is going to move forward. Given the investment in FPGA based SDRs, it seems to be a must-do.

It is worth noting that there is a far-term solution to this, which is the design and implementation of GPU-based SDRs. As was briefed at the last Friedrichshafen ham radio conference (IIRC), such a radio is currently being designed. With raw ADC data moving via PCIE to a GPU at the full sample rate of the ADC, the FPGA requirements become minimal, responsible only for managing the PCIE interface and housekeeping functions. This will significantly reduce FPGA cost, and even more significantly reduce the complexity of the code on it. The core SDR code can all move to high level language programming, thereby allowing a MUCH larger population of potential contributors to the codebase (nobody needs to be a firmware developer) and development environments will remain in the no/low cost regime. Experimentation and development will be much easier without having to mess with FPGA simulation, build times and timing verification. Code it, try it, no waiting. Hardware performance increases will be driven by the global GPU market, thereby allowing replacement of the GPU separately from the radio hardware, the latter requiring design spirals far less often.

Surely there will be challenges with these early GPU based designs. I'm concerned about noise from the PC getting into the radio PCIE card analog sections. But surely these will be overcome. Form factor will become a bit odd, with a PCIE card attached to an external RF hardware unit, or embedded PCs inside radios, but that will ultimately sort itself out as well. However, we won't see radios as small as the ANAN-10 series anymore as the GPU model is simply not as space efficient as a pure FPGA design.

Just to complete the story - yes, Thetis has continued to receive attention. Most (likely all) enhancements to PSDR/OpenHPSDR mRX PS that have been made recently have also been carried over into Thetis. Doug gets the credit for keeping this happening and in sync.

Chris, I fully agree that the software is coming along nicely and you, Doug, Warren, and others are doing a great job. However, without working firmware we can't get to the next level that so many have been waiting for.

Scott mentions the Minerva project and that certainly looks promising but I don't think it is eminent. This also makes for an even "fatter" client architecture which brings on its own problems. Many will need to upgrade their computer systems. 1000 base T is actually stressed for this architecture and likely not the best connectivity choice. We're probably going to need 2000 bps minimum to be "comfortable". That brings new challenges.

I continue to think that short term, Apache taking over the firmware development makes the most sense to me. Of course, it's not my money!

Joe-W4WT wrote:Scott mentions the Minerva project and that certainly looks promising but I don't think it is eminent. This also makes for an even "fatter" client architecture which brings on its own problems. Many will need to upgrade their computer systems.

This is probably not the case. Other than the fact that some people may need to add an NVIDIA CUDA-capable GPU, normal CPU processing requirements should not change appreciably. Also, what's very interesting is that AD0ES has been architecting the code to support a client/server architecture. Right now it appears one will need to provision a Linux machine with a Minerva and GPU to make this all work.

I haven't done the math but my gut tells me 1000 bast T won't support two data streams simultaneously from two ADC's able to handle 160 through 6 meters. Perhaps it will.

I knew AD0ES was working with Minerva using Linux but didn't know about the client server approach. I like that idea particularly if the server device could be a single board computer. I assume then that the server would essentially be the "FPGA" and you could run Thetis (or Simons software) on your Windows client system.

Joe-W4WT wrote:I haven't done the math but my gut tells me 1000 bast T won't support two data streams simultaneously from two ADC's able to handle 160 through 6 meters. Perhaps it will.

Joe,

I'm not sure what you are trying to say. Ethernet speed has little to no bearing on a GPU-based SDR architecture. For a GPU-based architecture thick client, there is no use of Ethernet whatsoever. All data flows over PCIE. For client server, there is only display and audio data, which will amount to less than 2Mbit/s, typically.

If you are talking about Protocol 2 on the current radios, Thetis only supports RX1 and RX2 at 1.5Msamples/sec, maximum. This is easily within the capability of Gigabit Ethernet, even with all of the "hidden" DDC traffic associated with PureSignal. Total traffic will be under 25% of the available link bandwidth.

I understand why you are confused. It is because I was confused! I went back and looked up the info for Minerva and see that I was mistaken in my thought that it still used an Anan radio for RF data. I see that is not the case as Minerva would do away with the Anan.

I think I was stuck further back when I think the discussions were to run Gig data from an Anan with a simple program in the FPGA back to the computer which then handled the bulk of the DSP work. In this scenario, a LOT of data needed to be moved from the Anan to the computer if you wanted to send two data streams of wideband data from each ADC to the computer.

UPDATE: on this past Friday's Teamspeak online teleconference, Phil reported that he had engaged directly with Altera and was now receiving direct Altera support to assist with timing closure.

Not heard on the telecon, it is my understanding that Altera's initial response was that the problem was limitations in the capability of the free Quartus Prime Lite development environment. Unsurprisingly, Phil reported on the telecon that the Altera applications engineer was getting substantially different results using Quartus Prime Standard.

Note that Phil develops for the Hermes first, then those results are ported to Angelia/Orion/Orion MkII by Joe. Thus if there is any success it will likely be on the Hermes platforms first.

There you have it: good news in that the developers have engaged directly with Altera, and some forward progress. How quickly it moves forward is anyone's guess. And there remains the very high likelihood that the answer will be "You must develop using Quartus Prime Standard". How the open source contingent will react to that also remains anyone's guess.

Thanks for the summary Scott. The timing closure problem is certainly a concern for all current and future owners of the ANAN hardware as it appears that in spite of the best efforts of our talented guys who are doing the heavy lifting with firmware development it looks like Quartus Prime Lite is not up to the task. Hope this gets resolved shortly so the platform can keep moving forward.

73,

Rob W1AEX

"One thing I am certain of is that there is too much certainty in the world."

Update: there's been some definite progress on the firmware. Another ham has very generously offered up his time and skills to help the firmware team (I'll let him "out" himself if he so chooses), and the contributions of the Intel FAE appear to be helpful as well. There is still much work to be done, but this is the first significant forward progress in some time.

I wouldn't hazard a guess at a any sort of time frames for firmware that I'd consider a "daily driver". And as the firmware shapes up a number of bugs are now starting to become apparent in Thetis as well. And, of course, there is still no 7000 support in Thetis.

I'd still recommend patience. If you can't stand the curiosity, don't forget that you had better be comfortable with Bootloader so that you can go back to a production release of Protocol 1 firmware after you have satisfied it!

I'm so happy to find out that I was wrong, and that it was not an issue of needing the standard version of Quartus Prime.

As noted on Teamspeak, there have been major strides made over just the past week's time. I'd now be comfortable predicting that there could be a new round of P2 firmware releases in just a few more weeks.

Note that, even with stable firmware, Thetis is still beta.

Note also that I am given to understand that on Hermes (any variant) and Angelia boards it may be necessary to replace or bypass one of the on-board circuit protection devices (a PTC type self resetting fuse) on the 3.3V supply rail. On Angelia that would be F3. It seems that an FPGA pulls a bit more current running P2 firmware and causes the PTC to run a little close to the edge of its ratings. However, perhaps we'll get lucky and the new, improved firmware won't exhibit that same issue.

W2PA wrote:Just to complete the story - yes, Thetis has continued to receive attention. Most (likely all) enhancements to PSDR/OpenHPSDR mRX PS that have been made recently have also been carried over into Thetis. Doug gets the credit for keeping this happening and in sync.

I have been using PowerSDR for a few years up to the latest 3.4.9 version and everything has been working fine. Lately I started to work with Thetis and encountered 2 major issues with it and a few minor ones.First: VAC mic TX on VFO B is not working. I am using ASIO and it works fine (both headphones and mic) on VFO A. However, when I click on TX VFO B - the mic does not work. The headphones work fine in MultiRX mode.Second: The VOX is not working properly - it is activated by voice, but then it bounces on and off during transmission.Attached are the relevant screens. Am I doing something wrong? Please advise.This is Audio settings screen:

"As noted on Teamspeak, there have been major strides made over just the past week's time. I'd now be comfortable predicting that there could be a new round of P2 firmware releases in just a few more weeks.".

We're now almost four months later and still nothing to see. No one even discusses this anymore on Teamspeak. Has Thetis been abandoned?

No, Joe, neither Thetis, nor Protocol 2, has been "abandoned". Unfortunately a higher priority issue came up, which is that all of the firmware including the bootloaders had to be redone due to a parts obsolescence issue with the memory chip used on the boards. That has taken a goodly bit of time and effort. And it's now summer, so people are busy with things other than radios, software and firmware.

Thanks for the info. It might be nice to have something like a monthly update just to keep everyone informed if this information is known by some. That would probably head off questions about it. When the last thing that is mentioned (that I've heard anyway) is that it would likely be available in a few weeks yet months later there is still nothing available and no info posted and no discussion on TeamSpeak, it obviously makes people wonder what is going on.

>"When the last thing that is mentioned (that I've heard anyway) is that it would likely be available in a few weeks yet months later there is still nothing available..."

We should always remember that the software side, and likely some or even much of the hardware development, is a volunteer effort. These folks owe us nothing, not even an update. It's their prerogative. PSDR mRx works and works well. Thetis is not a fix that addresses a fatal problem, although some of us think differently.

I almost never give time-lines to my clients in matters that are beyond my control. In nearly every instance where I've quoted an approximate date, I've been burned - even with date ranges. For example, when I tell a client it will take 3-5 months for a federal adjudication to complete, what number do they remember? What number do they never remember?

I was going to respond at length to your post but I don't want to upset some sensitive individuals so let me just say that I respectively disagree with the "status" part of your post. I never said the developers should provide a status. We purchased this hardware from Apache Labs. In my opinion, THEY are the ones that should be providing us a monthly status on the development.

I was a "developer" myself for many years. I wrote, published, and sold one of the first Ham Radio logging programs in the late 80's for 15 years so I understand how all this works from a developers point of view as well as a marketers point of view.

Joe-W4WT wrote:We purchased this hardware from Apache Labs. In my opinion, THEY are the ones that should be providing us a monthly status on the development.

How do you figure that, Joe? Apache doesn't produce the firmware, the software, or any documentation of the firmware or software. All they owe us is hardware that works and documentation of same. I will say that I do wish the hardware documentation was a bit better, but at least we have all the schematics (7K and 8K schematics must be requested directly from the factory, though).

Apache has, of course, tried to be helpful with dissemination of software and firmware, and has certainly been extremely supportive of the open source development community. It's in their own self-interest, obviously. But this causes it to appear that Apache is somehow also responsible for both of those things, and nothing could be further from the truth. Perhaps they could be a bit clearer on that matter in the future, but that doesn't change the facts.

I'd actually like to see Apache hire a few young software and firmware engineers and make some derivative works from the existing open source software and firmware. This would speed both development and innovation. And I'd be happy to pay more for the hardware or software to get that. But I'm not a purist where open source is concerned. You should read all the people crying a river on the original HPSDR mailing list about how the Gerbers are not available for Angelia or Orion boards. They expect Apache to give them away for free. I say they can do their own layouts from the open source schematics and BOMs, just like Apache did! But I digress, and I don't think that Apache is going to decide to get into the software and firmware business.