I’m putting the challenge out here this Sunday morning (in Iowa) to all the software developers out there:
THERE NEEDS TO BE A HERMES PROTOCOL I OR PROTOCOL II TRANSLATOR CREATED FOR THE LIMESDR SUCH THAT POWERSDR CAN FUNCTION WITH THE LIMESDR.
There…I’ve put it out there. The challenge (to a developer) would seem pretty straightforward because its taking opensource software from TAPR and applying LimeSDR API calls instead of what’s required for TAPR or Hermes architecture SDRs. If you want to be paid for that effort, there are Hams lined up to make that happen.
Change my mind if you think this isn’t possible because I think it’s entirely possible…1, 2, 3…GO…!!
One question: LimeSDR-USB and/or Mini to work with PowerSDR-OpenHPSDR version? If I understood correctly and after short peek to source code on GitHub it will be necessary to change OpenHPSDR as well!
I understand, it is best to have newest gateware versions but this is not my question. I will ask again: who will change OpenHPSDR? For start it does not allow SDR hardware to run on the same PC, sample rate is to small (384K maximum which is to small for LimeSDR to cover HF unless decimate samples) and more…
The developer who takes this on will be the one to make the changes to the code and overall sampling structure if necessary - they (or you) know more than the rest of us do…Also, it’s not accurate to say that the SDR that is attached to the platform cannot be the same one that runs the code - There are some SDRs that run on USB that are controlled by the application software on the same machine and it runs fine…
Based on what I read, the Hermes protocol sends XML over TCP. The application written for the LimeSDR would listen on TCP for changes based on the user input. You can tell that I didn’t read specifics about the Hermes protocol.
Actually, if someone were to take the actions where the Hermes radio is written data and just convert that to LimeSDR equivalents (and I’m not saying there wouldn’t be code re-written for that, too, to make it work with the existing algorithms) then it might be possible to have PowerSDR function for the Lime - I think this is how LinHPSDR and PiHPSDR do it…
Also, when you’re looking at the command structure of Hermes radios, determine the content that needs to be being sent to the Lime through the command structure, but don’t think you have to re-use the Ethernet that’s there - - you’re replacing that with the Lime API calls but loading the functions from OpenHPSDR/PowerSDR with the Lime API calls to send over USB to the Lime. The thing to do is to do a few simple ones like change the receive freqeuency or set the transmit frequency commands, then see if the Lime responded to that by reading it back (if possible) or just seeing how it was affected - maybe using LimeSuite or some other app.
The Ethernet interface in NET Hamlib rigctl was a way to make the LimeSDR respond to commands without modifying code of those applications that already include Hamlib. Or in other words, keeping the interface simple and adaptable to future changes. (or this)
Here, there will be future software updates to OpenHPSDR-PowerSDR, openHPSDR Ethernet Protocol version and the LimeSuite API.
This is UDP over Ethernet. The first documents I found when searching for Hermes Protocol where the wrong ones to look at.
All good - if you’re going to base this off Hamlib then that’s fine. Keep me advised of your progress there.
The intent of the first document was to point out the radio commands - those index back into the application as calls…It’s good to know both ends when trying to relate this to the LimeSDR.
I sure wish someone would take this on.
Simon (SDR-Console) has pretty much given up.
SDRAngel is confusing as heck to me.
I try to download the SDR# & get Trojan alerts.
I have all of the hardware set to go, but no one will do HF TX (SDRAn gel has it, but is difficult to understand).
Both of my LimeSDR-USBs are packed away. I won’t bother to unpack them, until someone actually works on this. Not just lip service.
I’m sick of making donations for no action.
Hey - I’m not sure if I mentioned that PiHPSDR (for a Raspberry Pi) is set to work with the Lime but not entirely certain if HF has been worked on it or not. I need to confirm that and I will this evening and let you know. There is also a ‘companion’ app for Linux called LinHPSDR that is not currently developed for the Lime, but has all the hooks for it in the code. The Ham that manages both of these code areas is John Melton, G0ORX, and I will give him a ping and see if he’s close to getting this to run on the Lime. It’s not Windows, but it does play on a PC under Ubuntu 18.04. Again, I need to confirm that it works with the LimeSDR on PiHPSDR for HF…I will check that out tonight.
I share your grief with this. I have A TON of time invested in the LimeSDR and all the while the developers are all going mad developing QO-100 (Es’Hail) capability into their code that works with the Lime, but not even giving HF a look. You cannot know how hard I’ve hammered on this to get something or someone to get HF transmit working on the Lime on Windows - but Simon just won’t work it for SDRConsole - the reasoning behind it is very unclear and the stumbling blocks have been taken away (meaning, I’ve told him in no uncertain terms that the LimeSDR operates in HF as well as some commercially made radios if given the chance).
Don’t give up just yet - this SDR is still the widest banded SDR out there - no other SDR comes close in terms of tuning and performance. We just have no one interested or focused on this despite $700 being on the line to give to the first developer who can prove a working app for the Lime that does HF transmit and receive…it’s just astounding. 2 years and…nothing. Yet the technological barriers are greatest (The Lime has no 10 GHz capability unless they have an LMS-8002) where they’re all spending their time (QO-100 aka Es’Hail).
Marty, I just wish it was different. But, you saw Simon’s response. My last donation was to encourage HF & I got nothing for it. It’s all just staying in boxes.
The trivial things that he has worked on “O” instead of a zero… Baffling…
Calling HF TX “Pointless”? As you have shown, it can work & well.
Kinda like having a picture of your wife. You can kiss it, but you get nothing back.
Frustrating.
Again, it will all stay in a box & my money will stay in my pocket, until someone actually works on it.
I made an amazing discovery last night and it was purely by accident that I did it. I knew that PiHPSDR would work with the Lime, but only on USB 2.0 since the Pi (now, the Pine Rock64 is an entirely different discussion because it has USB 3.0) cannot provide USB 3.0. But I was doing some testing with the LimeRFE last night using my Dell tower i5 PC under Ubuntu Linux 18.04 (Bionic) and found that LinHPSDR actually DOES see the LimeSDR (on USB 3.0) when it goes through discovery mode, and DOES actually launch and receive in the HF band (albeit a little choppy - I think John Melton (G0ORX) has more to do with it) and I found that it WILL transmit in the HF band, too…! (again, a little choppy but John probably has a little more work to do on it).
Outside of SDRAngel (which actually does receive and transmit incredibly well on the HF band) LinHPSDR is going to feel A LOT better to you because it has a more normal/typical user interface than SDRAngel does - almost like the PowerSDR GUI. So, I’m going to check in with John and see if there’s been any improvement with LinHPSDR since the last time he updated it - I’m due to pull and compile it again. But the major thing is - there’s one more app out there with a more familiar GUI that supports the Lime, and more will follow I’m sure…
I will look at it. Not really wanting to go Linux, but if it’s really the only way to have an intuitive GUI, it may be the ticket. Unless it’s actually working or in beta, with active work on the HF side, I will leave everything packed. If so, in November, I will be in the new house.
