Sequence errors during transmit

[n2gq]

Hi
I received my Anan-7000dle mk3 tuesday. I installed protocol 2 firmware and latest thetis and installed the patch as well for fm/eer.
I have a dedicated tplink network card for the radio. I also followed w1aex static ip instructions. I also configured card for ipv4 only with the npcap only.
Okay when receiving I am not getting any sequence errors, only on transmit. I have tried most suggestions here on the board. I have reset the database. The static ip gave good results. I can't get the nic to stay in private. It always revert back to public.
I have program the radio back to protocol 1 to see how it performs. And it works great. I am wondering if I missed something?
Computer is a AMD ryzen5 5600x 6 core processor and 16 gigs of ram.

[w-u-2-o]

Are the seq errors resulting in any noticeable degradation of your transmit audio? If not then you can ignore them.

Public/private doesn't really matter.

In Thetis Setup > General > H/W Select have you enabled Network Throttle Index Tweak?

You can try disabling Windows Firewall on the dedicated TP-Link NIC and see if that helps.

Finally, you can try messing with some of the advanced properties of the NIC, e.g. flow control, etc. and see if that makes any difference. There is no specific guidance on this, every NIC is different.

[Carajo]

I feel your pain, this is unsat. also W2UO wrote

There is no "issue" with the Mark III and Protocol 2 per se. There are issues with Protocol 2 overall. P2 firmware puts greater demands on both the FPGA (to achieve timing closure) and the Ethernet connection (Gigabit speeds and UDP packet loss rates). Some ANAN units have difficulty with it, although this tends to be rare. More often it's network related and it can fixed as described above.

It's unlikely that there will be any more versions of Protocol 2 firmware made.

I am contacting apache about sending me a radio that works with PROTOCOL II< I did not invest the money to go back to Protocol 1. or they can start sending me a refund.

[w-u-2-o]

As it happens, there will be another P2 firmware version coming out for EP4CE and 5CEFA based hardware because a bug was found in the QSK code in the current builds. So that might (or might not!) fix any problems. When the new firmware will be available I cannot say. It has to go through some alpha testing first before any beta might be posted.

However, it still begs the question: are any of these seq errors causing audible issues? If not then while they are annoying they are not functionally significant.

[n2gq]

Are the seq errors resulting in any noticeable degradation of your transmit audio? If not then you can ignore them.

Public/private doesn't really matter.

In Thetis Setup > General > H/W Select have you enabled Network Throttle Index Tweak?

You can try disabling Windows Firewall on the dedicated TP-Link NIC and see if that helps.

Finally, you can try messing with some of the advanced properties of the NIC, e.g. flow control, etc. and see if that makes any difference. There is no specific guidance on this, every NIC is different.

Hi,
Thanks for replying. I have the network throttle index tweak on. I had disabled the firewall on norton 360 and had checked all the rules. And on the advanced side of the nic I had turned flow control and most of the other parameters that were in a flex radio bullentin. The static ip was a lot of help. Before most of the adjustments I had sequence errors on both rec and trans. Then after all adjustments I had the receive working great but when I transmitted I would see a power output drop and sometimes a small spike in output power along with the sequence errors alerts popping on the screen.

[w-u-2-o]

You are already doing everything in the cookbook. The only thing I have left to offer is to try messing with some of the advanced settings. Over the years I've found that the advanced settings that have had the most dramatic effects for me were flow control and interrupt moderation. For instance, on my old NIC (that got killed by lightning--RIP!) it worked much better with interrupt moderation turned off. But my new NIC works best with all of the default settings. It's just something you'll have to experiment with and any changes have a low probability of success.

[n2gq]

Okay I will try some of those settings I hope I get something going. Will keep you posted.
Thank you
Jay n2gq.....

[n2gq]

I feel your pain, this is unsat. also W2UO wrote

There is no "issue" with the Mark III and Protocol 2 per se. There are issues with Protocol 2 overall. P2 firmware puts greater demands on both the FPGA (to achieve timing closure) and the Ethernet connection (Gigabit speeds and UDP packet loss rates). Some ANAN units have difficulty with it, although this tends to be rare. More often it's network related and it can fixed as described above.

It's unlikely that there will be any more versions of Protocol 2 firmware made.

I am contacting apache about sending me a radio that works with PROTOCOL II< I did not invest the money to go back to Protocol 1. or they can start sending me a refund.

Hi
I would not give up on this radio none are perfect. But it does work nice on protocol 1. And hopefully they can resolve the the timing issue. I have made about five on air transmissions with this radio. Not much fun with the radio yet but I like it so far.
Jay n2gq

[n2gq]

Good evening,

Okay this is what I did and the sequence errors have gone away. I went into tp-link network card properties and disabled most of the parameters that were enable. Now what actually helped is the parameter [Speed & Duplex] which I set it to 100mbps full duplex not 1000 gbps. And I swiitched back and forth between the two 100 then 1000 and everytime I chose 1000 gbps and sequence error popped up. Give it a try. Hope it helps.

Jay
N2GQ

[w-u-2-o]

Okay this is what I did and the sequence errors have gone away. I went into tp-link network card properties and disabled most of the parameters that were enable.

It would probably be better to leave all the off-loading options turned on. That makes things easier on the NIC.

Now what actually helped is the parameter [Speed & Duplex] which I set it to 100mbps full duplex not 1000 gbps. And I swiitched back and forth between the two 100 then 1000 and everytime I chose 1000 gbps and sequence error popped up. Give it a try. Hope it helps.

Unfortunately that approach has two problems.

The first problem is that there will be limitations on the max. number of receivers, sample rates, PureSignal and diversity. Depending upon what you are doing you can quickly exceed 100Mbit/s on the Ethernet interface.

For example, I normally run 768KHz sampling rate on both RX1 and RX2. When I have both receivers enabled and transmit with PureSignal the total data rate exceeds 100Mbit/s.

You can watch your data rates using the "resmon" tool built into Windows. It's like Task Manager but better. Just hit Windows Key + R on your keyboard and type resmon into the run box.

The second problem is that the ability to run at 100Mbit/s is an undocumented/unsupported feature. It only exists in the EP4CE and 5CEFA firmware builds. And because it made it so difficult to achieve firmware timing closure it is going to be removed as part of the upcoming firmware update to fix the QSK bug in those builds.

[n2gq]

Yes you are correct about sample rate. When at the largest sample I can't enable diversity. But when I lower to 768.... sample rate then it works.
I don't have a sampler for the pure signal yet so I don't know how it affects it but i'm sure as you said there will be a limitation.

Jay n2gq

[K1LSB]

You don't need an external sampler to test for proper PS operation, you can just use the internal sampler:

Gen Ant-Filters Antenna.jpg (116.49 KiB) Viewed 508 times

Mark

[w-u-2-o]

You don't need an external sampler to test for proper PS operation, you can just use the internal sampler:

Gen Ant-Filters Antenna.jpg
Mark

Unless he's using an external amplifier...

[K1LSB]

Regardless of whether he's using an external amplifier or not, he can test for proper PS operation by using my suggestion.

His PS won't correct for an external amp but it will still correct for the internal PA, so he can in fact test for proper PS operation.

Mark

[n2gq]

I am going to try a PS test today. Hopefully if I get time. Are any of you guys operating with a new mk3 chip and had any success?

Jay n2gq

[w-u-2-o]

I am going to try a PS test today. Hopefully if I get time. Are any of you guys operating with a new mk3 chip and had any success?

Jay n2gq

Jay--AFAIK, you are the only person with the most recent FPGA that has reported an intractable problem with a GigE connection.

[n2gq]

Now I am back to this issue.
I am able to run at a sample rate of 384000 with Pure signal and Diversity enabled and no sequence errors. The network adapter set at 100mbps.

Jay n2gq

[K1CWD]

I am going to try a PS test today. Hopefully if I get time. Are any of you guys operating with a new mk3 chip and had any success?

Jay n2gq

Jay--AFAIK, you are the only person with the most recent FPGA that has reported an intractable problem with a GigE connection.

I am also having the problem with my MKIII. It just started a few weeks ago, and was concerned it was a windows OS update issue, but it seems like this is more about the FPGA. I have done a number of large FPGA designs, and this gets me worried since the sequence errors have a large enough impact on operation to make me want to shut the radio down and use something else. Also concerned this just started happening, so not sure what might be drifting to cause a timing problem in the ethernet subsystem.

Any more insight into the next FPGA firmware drop?

[w-u-2-o]

Any more insight into the next FPGA firmware drop?

I know that Rick, N1GP, is working on a new drop for the second and third FPGA revisions in order to fix the QSK bug. There is no schedule for this, and since the code for the MAC and PHY interface on the FPGA will not be touched there's no expectation that it will attain better timing closure.

If you have done a large number of FPGA designs in a professional development environment, then you are better than able than most to appreciate the challenges, which are:

- The area of timing closure that is at issue is that of the MAC-PHY GigE interface. The remainder of the code runs at substantially slower speeds and has not proven to be a problem.

- openHPSDR firmware development has always used the free version of Quartus. This version does not allow for floor planning or incremental builds. Thus the critical GigE timing closure becomes disturbed for even the smallest changes elsewhere in the code.

- There has never been a formal thermal/voltage study done on the hardware design, so inputs to the Quartus timing model in this area are only a rough estimate. Rick has made substantial improvements in this area but the model settings are still a guess.

- The MAC-PHY interface code was homegrown (not by Rick, he inherited it) and does not use commercial IP. Therefore it quite literally is "amateur built".

As a result, whenever there is a new build of P2 firmware the best Rick can hope for is that if it closes timing on the single development system he has that it will also do the same for a small alpha test group, and then subsequently for a larger beta test group, the latter essentially being everyone. This used to rarely occur (you can look through the older P2 development threads on this forum to see that). Rick has developed an amazing feel for what will work, however, and his latest builds tend work on the vast majority of systems with few revisions. However there is no guarantee they will work on every serial number.

All in all, this is obviously not the most structured or desirable development environment, but it is what it is. If you feel like you might like to assist with firmware development please reach out to me.

73,

Scott

[K1CWD]

Any more insight into the next FPGA firmware drop?

I know that Rick, N1GP, is working on a new drop for the second and third FPGA revisions in order to fix the QSK bug. There is no schedule for this, and since the code for the MAC and PHY interface on the FPGA will not be touched there's no expectation that it will attain better timing closure.

If you have done a large number of FPGA designs in a professional development environment, then you are better than able than most to appreciate the challenges, which are:

- The area of timing closure that is at issue is that of the MAC-PHY GigE interface. The remainder of the code runs at substantially slower speeds and has not proven to be a problem.

- openHPSDR firmware development has always used the free version of Quartus. This version does not allow for floor planning or incremental builds. Thus the critical GigE timing closure becomes disturbed for even the smallest changes elsewhere in the code.

- There has never been a formal thermal/voltage study done on the hardware design, so inputs to the Quartus timing model in this area are only a rough estimate. Rick has made substantial improvements in this area but the model settings are still a guess.

- The MAC-PHY interface code was homegrown (not by Rick, he inherited it) and does not use commercial IP. Therefore it quite literally is "amateur built".

As a result, whenever there is a new build of P2 firmware the best Rick can hope for is that if it closes timing on the single development system he has that it will also do the same for a small alpha test group, and then subsequently for a larger beta test group, the latter essentially being everyone. This used to rarely occur (you can look through the older P2 development threads on this forum to see that). Rick has developed an amazing feel for what will work, however, and his latest builds tend work on the vast majority of systems with few revisions. However there is no guarantee they will work on every serial number.

All in all, this is obviously not the most structured or desirable development environment, but it is what it is. If you feel like you might like to assist with firmware development please reach out to me.

73,

Scott

Thanks Scott,

I do appreciate the technical issues you enumerated. I had no real understanding of the engineering/production environment Apache Labs is working with until reading some of your most recent comments. I have to admit though I'm a little surprised. I thought everything up to 2.5Gbit/s these days was fairly low risk and everyone implemented the reference design without significant modification. Would think too they would contract out for thermal qual.

All the SOC stuff I did was with Xilinx in VHDL, but it's possible I could help out. I would have to think about that a little since I retired recently, am a little hesitant to commit to new work, and most of my recent work was in the project management role (although I have been perusing some development boards to play around with).

73, Craig

[w-u-2-o]

Craig,

You wouldn't be committing to anything. One does not commit to open source, at least not in any fiduciary way

You might not fully appreciate how strange or unique the situation is. Apache does not have an environment for software or firmware development. They don't do any of that. See also:

viewtopic.php?f=9&t=4531

and

viewtopic.php?f=32&t=4004&p=17441

73,

Scott

[K1LSB]

Nor will you get paid for it.