apache-labs.com

Hello to all. I just acquired a 7000DLE and have a problem that some Protocol 2 guru will understand, so here goes.

It appears that I have a Protocol 2 problem and I have the problem identified. I just don't know why. I have a workaround but it's not a fix. My network configuration is not prohibitively complex but it is not simple either.

I am using a 7000DLE and a NUC 8i5 with Windows 10. This new release of Thetis, now 2.8.9 is probably the reason I've been able to identify the problem. The concept of allowing it to run with P1 or P2 was genius!

With P1, I've never had any problem at all. openHPSDR 3.4.9 has run great for a couple of years. Monday I loaded the new Thetis 2.8.8. It ran perfect also on P1. So then I decided to go to P2. It refused to run with P2 loaded. This has been tested with a 200D and my 7000DLE with the exact same response.

When starting Thetis on P2, the main form would appear and when I clicked the start icon, it would illuminate for a couple of seconds and then Thetis would shut down.

I connected the NUC directly to the 7000 and Thetis ran perfectly. When I connected them back into the network, it would fail again. I began removing devices from the network and identified 3 devices, any one of which would cause the failure. 2 were Raspberry Pi 4B's and the other was a Firewalla Blue. The thing they have in common is that they are ARM processors and each runs on a modified version of the Linux Debian OS.

Going back to the NUC, if you power it completely down and back up, Thetis will fail every time. If you check the ARP Table the radio does not appear, however the correct firmware information shows up on the setup screen in Thetis. That tells me that the NUC/Thetis and the radio have communicated. Now, if you manually enter the radio in the ARP Table or remove all 3 ARM devices, it runs like a champ, no failure.

It also runs fine, full network, with Protocol 1. No issues.

I am stumped!

BTW Thetis 2.8.9 is FANTASTIC! 73 -- Larry W9MDX

Just concentrating on the full network configuration:

When connected to your full network are you using DHCP or static addressing with the NUC and the 7000? If static, what addresses are they set to? If DHCP, what addresses are the being assigned?

Is the Firewalla providing DHCP services? What is its IP address?

Are the IP addresses of the Pi's assigned statically or by DHCP and what are they?

Thanks for your interest. I didn't want to get too detailed unless someone asked. It's probably not of interest to many.

First ... I am using unmanaged NetGear 1 Gig switches. I watched the ethernet activity thinking that maybe I was pusing their capabilities and not so. Using Protocol1 the network activity is about 54.5 Mbps and with Protocol 2 about 10.6 Mbps using 192 kbps scan rate for testing.

1) I always try to use static addressing. DHCP is allowed to assign addresses only in a specific small range (031 to 049) for unexpected circumstances where a static address cannot or it is inconvenient to assign. The DHCP server that does that is the cable modem/router (Arris).

Anan 7000DLE 192.168.0.73 (sorry!)
NUC 8i5 192.168.0.221

2) The Firewalla is NOT providing DHCP services. It's IP is set by DHCP and is 192.168.0.34

3) The 2 Pi's (Pi 4B's) are set statically and are used as servers or for network functionality. 192.168.0.5 is serving my web page (Apache) (http://w9mdx.com .net and .org) 192.168.0.6 is running PiHole and also serving as a local NAS Both are running the latest Raspberry Pi OS

Side note: I have a couple of spare NUC's (7i5's) I have them loaded with LMDE4 and necessary software and configured to replace the PI's EXACTLY. I have tried that by pulling the Pi's and the Firewalla and inserting the NUC's .. and yep, the problem goes away! Remember though that the Pi's are functioning without a burp!

Pi problem ... ehhh not necessarily but they do cause the problem to show up. I do really think that this is a timing issue with Protocol 2 and the reason is that with the full network in place and Protocol 1 loaded in the 7000DLE, there is no problem! I confirmed that with both a 200D and the 7K and with openHPSDR 3.4.9 and now with Thetis. It's only when I load either radio with Protocol 2 that I see the issue and it's exactly the same with either radio. The ARP Table in the 8i5 that runs the radio never gets populated with the radio's IP and Mac address. Thetis can't find the radio. Then if I manually place the radio's information in the ARP Table and start Thetis .. it runs well with no sign of a problem!

and Scott thank you for your interest! -- Larry W9MDX

Good data, Larry, thank you.

I don't know if you are aware of this, but if you are not, there is a fundamental problem with Protocol 2, and that is that, so far, nobody has been able to create a singular build (version) of the firmware that successfully makes (closes) timing on every serial number it is supposed to run on. This is a well known issue. It is why Rick, N1GP, developed, and why we posted, a long list of versions to try in each of the main "stickied" P2 firmware topics in the P2 firmware sub-forum (example).

In addition, it's my opinion that this issue is primarily associated with the GiGE MAC-PHY interface implementation. It is the only thing in the build that has to run fast. So many of the problems that people experience are actually related to Ethernet comm's. Seq errors, crappy IF data (exemplified by poor PureSignal performance, high noise floors, etc.) and, potentially in your case, what looks like failure of the firmware to perform ARP properly.

If you were aware of that, have you tried any other firmware versions that have been posted other than the one you are working with? If not, the you should. Using the 7000 again as an example, it would not be unusual for you to find that you might have to go back to a 1.9 or even 1.8 build to get it to work.

Note also that it is possible to get a version that closes timing for you when the hardware is cold, but starts to act up when the hardware warms up, or vice versa, so be on the lookout for that.

73,

Scott

P.S. all honor to Rick, N1GP, by the way. Before Rick took his turn at it, P2 firmware was so bad it would run on maybe one out of every ten serial numbers. He fixed a LOT of stuff, and worked on changing some of the thermal modelling. Now it is generally possible for nearly everyone (but, sadly not everyone) to find a version that closes timing on their hardware. What we need next is for someone to take 10 serial numbers, a logic analyzer, and a non-free (very expensive) version of Quartus Prime and figure out what is really going on between the MAC code in the firmware and the PHY chip on the board. I don't think that is going to happen, though.

Scott .. that's funny.. go back to 1.9! I downloaded from GitHub and I thought that 1.9 was the latest! Your post makes it sound like there are later versions. tell me it's not so! I would be glad to try any other firmware version, if I can find it for download. Please understand the humor comes from the knots on my forehead formed while troubleshooting this problem!

Apparently there is a current issue with the Intel 1219-V network controller chips and how they handle collisions. Of course my 8i5 NUC has one of those. I also have a homebrew Asus MB with an i7-4790K that does not have that ethernet chip and it has the same problem. My hats off to Rick N1GP for even touching the P2 code. There are just too many variables to consider .. like the recent discovery of the 1219-V chip issue.

I'm just shy of going back to Protocol 1 and saying the heck with it. The new release of Thetis makes that a great solution to my problem.

--Larry MDX

Larry,

Did you not follow the link I posted in my previous entry in this topic? The one marked "example". Did you not peruse the various topics in the P2 firmware sub-forum?

73,

Scott

Scott .. I saw the link "example" ?? and finished reading your post first. I just downloaded the latest 2.0, the one with 360 downloads, and installed it. It fixes a couple of issues but the ARP Table problem is still the same. I've gone completely thru the material provided in your link.
Obviously Protocol 2 has some issues and I am disappointed that it has not received more attention. February 2020 is a long time ago. I will be following this "subject" and hope that I can help, in some way, resolve this problem. Right now, I can't even begin to point my finger and I'm not even sure if others, who are using Pi's on their network, are having the same exact problem. Thanks for your help!

--Larry MDX