Cant connect to Hermes Lite with any software

[Kerstan Moran]

I am trying to help a friend who has a working Hermes Lite using Thetis and then switched to SparkSDR. I can find the Hermes on the network via Angry IP scanner but nothing will connect to the Hermes. I have read and seen several articles about shorting the tip and ring at power on to make the Hermes go back to the default Gateware but this accompolishes nothing. Quisk will attempt to reload the gateware file, but it fails. Quisk will not show any details about the radio, temp, firmware, nothing. It looks like it also cant talk to the Hermes.

My friend is shipping me the radio so I am work on this at home instead of remotely via his computer. I should have it in a few days. I am going to try the Python scripts but cant do that until I get the radio. 

Is there a process to reset this radio back to default as it was when it left the factory?  What is the best way to unbrick this thing?

[Roger David Powers]

My $0.02 is to follow the steps in https://github.com/softerhardware/Hermes-Lite2/wiki/Troubleshoot-Network .  The LEDs are pretty good at telling you what is or is not going on.  

Watching the connection using wireshark is somewhat helpful all on its own, but if your networking/hacking skills are up to the task, you may want to try https://github.com/matthew-wolf-n4mtt/openhpsdr-u which is a wireshark plugin for the protocol used by HL2.  It doesn't have all the HL2 'enhancements' last time I checked, but still it can be quite helpful if/when the LEDs leave some doubt as to what is happening.

And no, I don't know of any other way to do a factory reset than the tip+ring approach.

Regards,

RDP

[Steve Haynal]

Hi Kerstan,

As RDP suggested, please refer to the network guide on the wiki:

https://github.com/softerhardware/Hermes-Lite2/wiki/Troubleshoot-Network

The state of the LEDs is important to report.

There have been reports that fixed IP and/or favor DHCP settings change when changing software. Please boot in factory recovery mode (tip shorted to ring during power on) and check these settings in SparkSDR, Quisk or the Python scripts. 

It is very unlikely that it is bricked. The factory recovery mode uses an image stored in the flash which is very difficult to overwrite. I have seen cases where factory recovery mode is not correctly applied (bad cable, shorted at wrong time, no dhcp on network, user doesn't know about apipa address, etc.) so please pay careful attention to how you are doing that.

73,

Steve

kf7o

[Kerstan Moran]

I spent most of the afternoon working on the Hermes and had no luck. Per the troubleshooting guide the light indicate that either it has a static IP or it is in  APIPA. D2 is flashing, D3 is flashing, D4 is on solid (my network is all GB) and the Ethnernet activity and link lights look as if its connected. I scanned my network several times after unplugging and replugging the power and ethernet cables and never found the Hermes. I used WireShark to monitor BOOTP but never seen the device sqalking for an IP. I also connected the Hermes and my laptop together via a GB switch and set my laptop to the APIPA IP range, scanned many times and never found the device. I am waiting on the USB blaster to arrive.  I also tried via the Hermes lite Python script, quisk, SparkSDR and none of them would find the Hermes. I did the shorting out of the ring and tip of the PTT jack at boot up which is supposed to make the Hermes ignore a static IP (which is what I think it has) and use DHCP but it was never found on my network.  I am open for more suggestions if anyone has any. 

[Kerstan Moran]

Some additional information to share. My friend installed the  AK4951 companion board in this Hermes L2 and uses SparkSDR and loaded a Gateware update that is required for the comanion board and after that update is when the Hermes "dissapeared". I am going to remove the companion board and re-try all the previous testing and see if I can find the Hermes.  

[Kerstan Moran]

I am pleased to say that I got it working.  The problem was DHCP was turned off. I was able to turn that back on via SparkSRD. Now to learn how to use this thing. Thank you all for your suggestions and guidance. 

[Roger David Powers]

I am pleased to say that I got it working.  The problem was DHCP was turned off. I was able to turn that back on via SparkSRD. Now to learn how to use this thing. Thank you all for your suggestions and guidance. 

Thanks for your write-up.  I'm glad you got it to work!

It looks like I didn't cover the 'favor DHCP' flag when I wrote the network troubleshooting page. Hopefully I'll find some time to do some experiments with my HL2 and update the wiki accordingly.

I don't think 'favor DHCP' needs to be on if you haven't set a fixed IP address, but once you have, it will need to be on if you want it to use DHCP.  Maybe Steve can clarify.

It does look like the LEDs did tell you the issue was with address management, i.e. that the HL2 was online and was using the APIPA address.

At that point, assuming the HL2 was connected to the host via a router/switch, I would think only one-way communication would be possible.  The HL2 probably could see the incoming broadcasts of the discovery protocol and probably sent a reply but that reply probably didn't reach the host running the SDR application because the router/switch wouldn't deliver that reply to the host.

I have used APIPA a lot with the HL2 directly attached to a host, and it works because there is no router/switch in the loop so there was nothing to intercept the reply.  For it to work correctly though, you usually need to go into your operating system's network config GUI and tell it to not use DHCP on that link/interface but instead to use 'link-local' addresses.

In my opinion it's a good idea to use a direct connection so HL2 has a dedicated/isolated path to the host, but most people don't do this.  As mentioned in the troubleshooting page, the HL2 doesn't have a lot of space to buffer packets, and that can be problematic in some high-traffic scenarios.   

And it's probably a good idea to try a direct connection during debugging because running a sniffer like Wireshark on that host would have shown that the HL2 was alive and seeing the discovery packets and sending replies.

So I will have to think about how much of this additional info needs to be added to the network troubleshooting page.

Also, please let me know of any other ways that the page can be improved.

Regards,
RDP

[Kerstan Moran]

Hi RDP,

After asking my friend what he did when the radio stopped working was the key. He added the AK4951 companion board and their instructions are to flash a new gateware file. Well, their file turns off DHCP and with no static IP address the Hermes seems to go into la la land. I am an IT guy and I exhausted all my skills with varius different network/port scanning tools and never found the Hermes. After using the foil trick D3 would stay on and as soon as that happened I was able to find the Hermes with my IP scanning tool. I them used SparkSDR and looked at the advances setting of the gateware and the DHCP box was turned off. Once I ticked it from then on with their updated gateware the Hermes is acting exactly how it should.

I am now begining to experiment with the Thetis settings. I want to try to create the band and mode selectors for the 2nd receiver and I figured out how to replace the db s-meter with the Annon meter, I am NOT a fan of the db meters. I still have a lot of tinkering to do and a LOT to learn. I suspect I will be back asking a lot more questions. I will also take a stab at improving your troubleshooting guide. It was very helpful but maybe adding a few more things I found may make it easier for others. 

Regards,

Kerstan

[Roger David Powers]

After asking my friend what he did when the radio stopped working was the key. He added the AK4951 companion board and their instructions are to flash a new gateware file. Well, their file turns off DHCP and with no static IP address the Hermes seems to go into la la land. I am an IT guy and I exhausted all my skills with varius different network/port scanning tools and never found the Hermes. 

It would be interesting to know if you did this with the HL2 directly attached to the host running the sniffer, or if there was a hub/switch/router in between your host and the HL2.   I think I had a similar issue happen till I did the direct attachment.  The underlying issue that prevented me from seeing the HL2 reply to the broadcast was the router was not forwarding the reply from the HL2 back to the network so the sniffer never saw that reply.   In essence it was a "network issue" more than a "HL2 issue".  HL2 was sending a reply but from an IP address the network didn't assign (it was an APIPA address) so it didn't get forwarded.

After using the foil trick D3 would stay on and as soon as that happened I was able to find the Hermes with my IP scanning tool. I them used SparkSDR and looked at the advances setting of the gateware and the DHCP box was turned off. Once I ticked it from then on with their updated gateware the Hermes is acting exactly how it should.

Posts from Steve say that in factory mode the settings for DHCP that are stored locally are ignored, that's why you were able to use factory mode and get DHCP to work.  

Gateware that comes with DHCP disabled seems wrong to me.  I wonder if that was done intentionally or if it was a mistake.  The first post below suggests your friend isn't the only one who had to boot to factory mode then enable DHCP.

Some relevant posts:

• https://groups.google.com/g/hermes-lite/c/LRzOFGid6RA/m/JOb_m0BFAQAJ
  
• https://groups.google.com/g/hermes-lite/c/oeWFABtPPlI/m/sFSZ4dl7AAAJ
  
• https://groups.google.com/g/hermes-lite/c/f0SCd685V1k/m/wFrm9xBUAwAJ
  

Regards,

RDP

[Steve Haynal]

The ethernet settings are purposefully not stored in the same flash as the gateware. They are stored in some spare entries of the i2c variable potentiometer. The gateware version should not matter. I suspect accidentally disabling dhcp or changing ethernet settings when experimenting with different software.

73,

Steve

kf7o