Thetis ETA for release ?

Jdsbose
Posts: 8
Joined: Sun Apr 09, 2017 5:11 pm

Thetis ETA for release ?

Postby Jdsbose » Mon Jul 03, 2017 5:45 am

Just curious if there is any time line for release ?
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: Thetis ETA for release ?

Postby w-u-2-o » Mon Jul 03, 2017 11:11 am

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.)

73,

Scott
Jdsbose
Posts: 8
Joined: Sun Apr 09, 2017 5:11 pm

Re: Thetis ETA for release ?

Postby Jdsbose » Thu Aug 31, 2017 12:38 am

OK, 2 months later from my first inquiry. What is going on now with the protocol 2 firmware and thetis ? Update please.
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: Thetis ETA for release ?

Postby w-u-2-o » Thu Aug 31, 2017 1:57 am

Not very much progress to report.

Thetis remains essentially unchanged.

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.

73,

Scott
Jdsbose
Posts: 8
Joined: Sun Apr 09, 2017 5:11 pm

Re: Thetis ETA for release ?

Postby Jdsbose » Fri Oct 27, 2017 3:02 am

Now 4 months later since my first inquiry, and 2 months since my second, status update ?
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: Thetis ETA for release ?

Postby w-u-2-o » Fri Oct 27, 2017 10:37 am

Nothing to report, unfortunately. As far as I can tell, Thetis, and the new protocol, continue to be back burner items. Surely all focus is on the 7000 release right now.
Jdsbose
Posts: 8
Joined: Sun Apr 09, 2017 5:11 pm

Re: Thetis ETA for release ?

Postby Jdsbose » Wed Jan 10, 2018 4:53 am

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?
Joe-W4WT
Posts: 23
Joined: Sun Apr 09, 2017 5:27 pm
Location: Cumming, GA

Re: Thetis ETA for release ?

Postby Joe-W4WT » Wed Jan 10, 2018 5:42 am

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.

Joe W4WT
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: Thetis ETA for release ?

Postby w-u-2-o » Wed Jan 10, 2018 11:25 am

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.

73,

Scott
User avatar
Tony EI7BMB
Posts: 108
Joined: Sun Apr 09, 2017 2:31 pm
Location: Dublin
Contact:

Re: Thetis ETA for release ?

Postby Tony EI7BMB » Wed Jan 10, 2018 1:08 pm

Thanks for the update Scott, interesting reading.
User avatar
W2PA
Posts: 60
Joined: Sun Apr 09, 2017 6:34 pm

Re: Thetis ETA for release ?

Postby W2PA » Wed Jan 10, 2018 1:41 pm

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.
73,
Chris, W2PA
Joe-W4WT
Posts: 23
Joined: Sun Apr 09, 2017 5:27 pm
Location: Cumming, GA

Re: Thetis ETA for release ?

Postby Joe-W4WT » Wed Jan 10, 2018 6:08 pm

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
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: Thetis ETA for release ?

Postby w-u-2-o » Wed Jan 10, 2018 10:42 pm

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.
Joe-W4WT
Posts: 23
Joined: Sun Apr 09, 2017 5:27 pm
Location: Cumming, GA

Re: Thetis ETA for release ?

Postby Joe-W4WT » Thu Jan 11, 2018 12:05 am

Hi Scott,

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.

73,

Joe W4WT
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: Thetis ETA for release ?

Postby w-u-2-o » Thu Jan 11, 2018 4:12 am

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.

73,

Scott
Joe-W4WT
Posts: 23
Joined: Sun Apr 09, 2017 5:27 pm
Location: Cumming, GA

Re: Thetis ETA for release ?

Postby Joe-W4WT » Thu Jan 11, 2018 10:55 pm

Hi Scott,

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.

Sorry for the confusion.

73,

Joe W4WT

Return to “Thetis”