Re: Question on rx4000.py

[Roger David Powers]

I asked Steve some questions on the rx4000.py file in software/ft8 in github directly because I didn't think the answers would be interesting to others, but now that I have the answers I think they might be, so below please find my summary of our e-mail conversation.  Of course I may have misunderstood the answers and I am doing some interpretation and have restated a few things so all errors are my responsibility.   As you see I like to take notes in good old fixed width text.  I can reformat and put them in wiki if people think they are helpful, please let me know.

- Notes on _getdata() in rx4000.py:

  - Samples are divided by 8388607.0 (hex 0x7fffff) to convert the 24 bit 

    integer sample values to floats with range -1..1, 

  - 'I' samples are multiplied by  100 to provide gain

  - 'Q' samples are multiplied by -100 to provide gain and to work around a

    long standing bug in gateware and the applications that's too old to fix

- Notes on use of port 1024 vs port 1025

  - Gateware responds to commands to port 1025 as well as 1024 so that two

    computers and/or applications can interact with a HL2 at the same time

  - This allows hermeslite.py to connect on port 1025 at the same time as

    some other SDR application is connected on port 1024

- Notes on the sequence 0xef, 0xfe, 0x05 in ethernet frames

  - The 0xef, 0xfe, 0x05 sequence indicates a special command sent to port 1025

  - The definitive source code for what is recognized by the HL2 is in the

    dsopenhpsdr1.v file around lines 183 to 195:

    https://github.com/softerhardware/Hermes-Lite2/blob/master/gateware/rtl/dsopenhpsdr1.v

- My interpretation of (and comments on) the sequence 0xef, 0xfe, 0x05 

  - It's a mechanism to send a command to the SDR on the alternate port 1025

    regardless of whether or not the start command has been sent 

  - Python function 'command()' in hermeslite.py shows the message sent is:

    bytes([0xef,0xfe,0x05,0x7f,addr<<1])+cmd+bytes([0x0]*51)

    where command can be either a 32 bit number or a four byte sequence

  - 'addr' corresponds to C0 and 'cmd' corresponds to C1 C2 C3 C4 of the

    main openhpsdr protocol

- Notes on the 10 RX 'variant' image

  - The December 2020 build of the 10 RX gateware variant does not support port

    1025 or the 0xef, 0xfe, 0x05 sequence because of the need to conserve gates,   
    see line 100 of:

    https://github.com/softerhardware/Hermes-Lite2/blob/master/gateware/variants/hl2b5up_cicrx/hermeslite.v

  - If you need to use this 10 RX gateware or older versions and you don't 

    need to support two computers accessing HL2 at one time, then you should 

    be able to modify hermeslite.py to use port 1024 instead of port 1025,

    or just work with the standard 4 RX which supports port 1025 and the 

    command sequence

  - The July 2021 build of the 10 RX gateware variant does support port 1025

    and the 0xef, 0xfe, 0x05 sequence, there was enough space to enable it

Regards,
RDP

[Roger David Powers]

Follow up question: Is the 4,000 hz sample rate variant available for HL2 anywhere?  I see from the other thread it's just a small mod to the gateware code, but I don't have the tools or the knowledge base to rebuild gateware at this point in time.  Feel free to email me a pointer to private copies if it is not available publicly.

Regards,

RDP

[Steve Haynal]

Hi Roger,

Thanks for the update. Hopefully others will find it useful. 

You can find the 4000Hz version here:

https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/variants/hl2b5up_4000

Do you need general help in building it, or want a version which runs on the latest HL2 ethernet PHY? I should be able to help in about a week.

73,

Steve

kf7o

[Roger David Powers]

Hi, Steve.

I'm looking for the 4000 kHz gateware, it needs to be for hardware build 5 or later, does not need new PHY.  

I have not set up the gateware toolchain and at this point don't think I'll be doing a lot of rebuilding so I would favor a pre-built copy.

If there are instructions on what to do on linux and the toolchain is free I could have a go at it, but I'm a newbie when it comes to gateware and somewhat afraid I'd end up bricking the device, although I am aware of the fall back to factory image via shorting the key pins at boot time.

A bit of googling suggests the toolchain is huge so would take a long time to download and take up a lot of disk space, so again it's something I'd prefer to avoid.  It's also not clear which edition I'd need, if it's free or not, etc.

Regards,

RDP

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/e18c9d80-41b3-4d6d-a608-fd63e195ca7dn%40googlegroups.com.

[Steve Haynal]

Hi Roger,

I'll try to remember to add this to the supported variants once I am back home.

73,

Steve

kf7o

[Roger David Powers]

> I'll try to remember to add this to the supported variants once I am back home.  

No rush, Steve, I can make progress with the other variants.  I'm doing this work at a slow pace and I have commitments coming up for the week at least, and much of the fall will be busy with plenty of other things to get to, so whenever you get around to it is fine.  

As you know, 4000 sps variant is enough bandwidth for things like FT8 decoding and it greatly reduces the packet arrival rate compared to the next slowest rate, 48000 sps.  My observations show it is a lot of work to try to process multiple RX streams in Python at 48000 sps on a Raspberry Pi 4.   I can just barely receive two streams, any more results in packets being dropped.  With even just two 48k streams there is little capacity left over to do other things such as processing the received data. 

Given the desire to focus on FT8 decoding, most of the data is surplus to requirement so going to the 4k sps variant is a good expedient.   I'm interested to see the results with 48/4=12 times lower packet per second rate, but again, no rush.   

So, does the 4000 sps variant just remap the 48000 rate to 4000, or are all the sample rates scaled down by 48/4=12?  Is it based on the 4 stream TX/RX main release or on the 10 stream RX-only variant?  I supposed if I could read verilog I could figure this out, but so far I haven't learned it.  No real preference but I doubt I'll ever need more than four streams so basing it on the main release is fine by me.

Regards,

RDP

[Steve Haynal]

Hi Roger,

The 4kHz requires additional filtering (and resources) in the FPGA. You might want to consider C, Cython, or some other language for better performance of the RX stream processing.

73,

Steve

kf7o