Testing Gateware 20200222_69p3 Released
508 views
Skip to first unread message
Steve Haynal
Feb 23, 2020, 1:58:01 AM2/23/20
to Hermes-Lite
Hi Group,
Gateware 20200222_69p3 This is part of development for version 69 gateware. Please see the link for release notes. I appreciate any testing and feedback.
73,
Steve
kf7o
Dick k
Feb 23, 2020, 1:52:45 PM2/23/20
to Hermes-Lite
Steve,
In a future release, would it be possible to add the TQ(1 | 0 ) serial commands so an external controller like an ardiuno can control an amp using only the serial interface. TQ1 would be sent on transmit and TQ0 would be sent when returning to receive.
The command syntax example is from the Elecraft documentation, but syntax should be what ever makes the most sense.
73's
Dick
Steve Haynal
Feb 23, 2020, 9:46:24 PM2/23/20
to Hermes-Lite
Hi Dick,
It is a lot of work to support every peripheral out there. Instead, I provide a template/example of how to add a simple UART. Please see the HR50 interface module:
and how it is used in:
It works with these hardware IO boards:
If you do write a module that does what you want, please submit a pull request to github and I will included it for others to build custom gateware with.
73,
Steve
kf7o
Matthew
Mar 1, 2020, 2:41:28 PM3/1/20
to Hermes-Lite
I am nearly there with implementing cwdaemon into linhpsdr and using the cwx feature to key the HL2 via the TX packet. This allows linux logging software to either send macros or type keyboard CW.
I have done some initial testing with HL2 and listening to transmitted CW. Things are sounding a bit choppy at higher speeds (>30 wpm), but this could be any number of things I am doing wrong in software. The buffer under/over flow flags and variable tx buffer latency will be very useful for debugging this. Very interesting to experiment with.
Thanks for all your efforts Steve.
73 Matthew M5EVT.
Steve Haynal
Mar 2, 2020, 1:08:44 AM3/2/20
to Hermes-Lite
Hi Matthew,
Sounds good. Please compare with CWX in PowerSDR as that is what I've been testing with. Let me know if you see any common issues.
73,
Steve
kf7o
Matthew
Mar 3, 2020, 3:11:31 PM3/3/20
to Hermes-Lite
Thanks for the notes for getting PowerSDR working with wine. I used these yesterday and had no problems. I do observe with PowerSDR that sometimes the first dit gets missed depending on "CW Break In Delay" and the CWX speed (wpm). Cleary, CWX will be using the default values for TX buffer latency and PTT hang time. So I was wanting to tweak these in linhpsdr. In general PowerSDR is sounding a lot better than my efforts so far with linhpsdr.
In my code I have tried experimenting with the TX buffer and PTT hang time, I'm not convinced they are having any effect. I fear I am making a silly mistake. My code snipped is:
output_buffer[C0]=0x2E;
output_buffer[C1]=0x0;
output_buffer[C2]=0x0;
output_buffer[C3]=0x4;
output_buffer[C4]=0x1F;
output_buffer[C1]=0x0;
output_buffer[C2]=0x0;
output_buffer[C3]=0x4;
output_buffer[C4]=0x1F;
I can see in Wireshark these values do get sent in the C&C part of the TX packet.
Alan is usually fairly sharp at implementing these features, I'm wondering if you have noticed any effect with changing values for TX buffer latency and PTT hang?
73 Matthew M5EVT.
Steve Haynal
Mar 4, 2020, 12:44:49 AM3/4/20
to Hermes-Lite
Hi Matthew,
What you are sending looks correct. With Quisk I verify that TX latency is being set properly by printing out the TX IQ FIFO Count MSBs. Each entry in the TX fifo buffer represents a time delta of 1.0/48000 given the TX sampling rate of 48kHz. The lower 4 bits of the buffer are not sent, so each count of the TX IQ FIFO Count represents 16*1.0/48000 = 0.33333ms. There are 2048 entries in the TX buffers, so a total depth of 42.6666ms. The output below is for a single RX at 384kHz (more RXs and wider RXs means the TX IQ FIFO Count is set more often) when the TX buffer latency is set to 16ms. Note that in receive we are in an underflow condition of 0x80 as the FIFO is empty, no data is being pushed or pulled. The first 0x87 shows new TX data being pushed into the FIFO as TX starts. The underflow/overflow bit doesn't change immediately due to gateware sampling, so this is not a true underflow. The next few numbers show the FIFO filling up with new packets from Quisk and no underflow condition. Finally, we reach a stable sequence of 0x34 32 30 2e as the transmitter has waited the 16ms and now starts pulling data at a constant rate while Quisk is sending a packet roughly every 2ms. Note that 0x34 * 16 * 1.0/48000 is 17.333ms, pretty close to the target 16ms. You can see that Quisk is doing a good job of sending 1 packet for every X packets received, where 1:x is the lowest ratio for the number and width of receivers. Finally you can see the transmitter drain the remaining data from the FIFO at the end. Once there is no data, TX stops.
With linhpsdr I don't think the ratio is 1:X. Instead 8 full UDP packets are sent at a time. Each UDP packet has 2*63 FIFO entries, or 2*63*1.0/48000 = 2.625ms. So 8 consecutive UDP packets is 21ms. This is why the default TX latency is 10ms. If we see 21ms data sent in a very short time, in the worst case for a 42.6ms buffer, then 10ms latency gives us about +/-10ms jitter buffer without over or under flowing the buffer. Both PowerSDR and linhpsdr send a large number of consecutive UDPs which means there is less freedom to tune the latency. It would be interesting to find the sweet spot.
80 80 80 80 80 87 7 7 7 f f f f 17 17 17 17 1f 1f 1f 1f 27 27 27 27 2f 2f 2f 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 2c 2a 28 26 24 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 2c 2a 28 26 2c 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 2c 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 2c 2a 28 26 24 22 20 1e 1c 1a 18 16 14 12 10 e c a 8 6 4 2 0 80 80 80 80
80 80 80 80 80 87 7 7 7 f f f f 17 17 17 17 1f 1f 1f 1f 27 27 27 27 2f 2f 2f 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 2c 2a 28 26 24 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 2c 2a 28 26 2c 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 2c 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 34 32 30 2e 2c 2a 28 26 24 22 20 1e 1c 1a 18 16 14 12 10 e c a 8 6 4 2 0 80 80 80 80
73,
Steve
kf7o
Matthew
Mar 4, 2020, 3:58:43 PM3/4/20
to Hermes-Lite
Thanks for the detailed reply. I was so concentrated on these few addresses that I forgot you added the FIFO count MSBs. I'll do some more experimenting.
73 Matthew M5EVT.
Matthew
Mar 15, 2020, 4:23:59 PM3/15/20
to Hermes-Lite
This is still taking more time than I expected to get working well at faster CW speeds. I decided to try and save time by using existing cwdaemon code and the unixcw libraries. I'm not convinced I wouldn't have been better starting from scratch. Unixcw libraries have some problems that I have fixed. It compiled, but had very choppy transmission of cw. I can only assume linux (pulse and alsa) updates over the past few years have broken some of the code that perhaps once worked.
I do now have a cwdaemon like setup providing sidetone and keying the HL2 from my logging sofware. I'm monitoring the transmitted waveforms on a scope and at 40 wpm everything is looking good. The unixcw libraries have lots of iambic keyer code and a simple example code to turn a mouse into a paddle. I will try this at some point now I have a good foundation to build on.
My latest stumbling point was a period of low transmit power at the start of every CW transmission. I spent a long time chasing this bug down. I realised it has been present with linhpsdr for a while. The transmit power level is sent as 0 unless the radio is transmitting. However, with a key plugged into the HL2, linhpsdr doesn't know it is transmitting until a packet is received from the HL2 and processed. My implementation of cwx behaves in a similar manner (for now). Steve, can you think of any good reason not to send the desired transmit drive level all the time (e.g. when receiving)?
I'm not convinced that this cwx method brings any benefit over the method Alan created with SparkSDR by simply sending the "audio cw" in TX packets to the HL2. However, clearly it provides existing PowerSDR users with cwx capability.
73 Matthew M5EVT.
I do now have a cwdaemon like setup providing sidetone and keying the HL2 from my logging sofware. I'm monitoring the transmitted waveforms on a scope and at 40 wpm everything is looking good. The unixcw libraries have lots of iambic keyer code and a simple example code to turn a mouse into a paddle. I will try this at some point now I have a good foundation to build on.
My latest stumbling point was a period of low transmit power at the start of every CW transmission. I spent a long time chasing this bug down. I realised it has been present with linhpsdr for a while. The transmit power level is sent as 0 unless the radio is transmitting. However, with a key plugged into the HL2, linhpsdr doesn't know it is transmitting until a packet is received from the HL2 and processed. My implementation of cwx behaves in a similar manner (for now). Steve, can you think of any good reason not to send the desired transmit drive level all the time (e.g. when receiving)?
I'm not convinced that this cwx method brings any benefit over the method Alan created with SparkSDR by simply sending the "audio cw" in TX packets to the HL2. However, clearly it provides existing PowerSDR users with cwx capability.
73 Matthew M5EVT.
Alan Hopper
Mar 15, 2020, 6:37:45 PM3/15/20
to Hermes-Lite
Hi Matthew,
In Spark I send the tx drive level all the time ( based on that set for the foreground virtual transceiver) and never had any issues.
The only possible gain I see with cwx is that it can make less of a rf mess when the latency is reduced very close to the bone and a packet is delayed.
I've not had much time recently but am nearly there with very low latency side tone on win 10 and will tackle other platforms next.
73 Alan M0NNB
Steve Haynal
Mar 16, 2020, 1:26:45 AM3/16/20
to Hermes-Lite
Hi Alan and Matthew,
Yes, sending the TX drive level all the time is fine and preferred for the HL2. There is some SPI communication with small latency that occurs to set the TX drive level.
I added CWX mainly for PowerSDR compatibility and am also not convinced that it is the best approach. Sorry, but I haven't been working on much CW related stuff recently although I hope to get back to it.
I do have two changes to the gateware which I am cleaning up to release soon. First, I've enabled support for a second gateware image in the EEPROM. The first, or factory image, is never modified by the user and will be loaded if there is any problems with the second, or application image. This is extra protection for those who have experienced problems updating over the network. Second, I have switched from SPI-based updating of the LNA gain to fast TX channel updating of this gain. This is to facilitate fast hardware-based and properly timed switches between two LNA gain settings with RX and TX. Currently the gateware has only one gain setting, although some software manages two different gains for RX and TX. This is for PureSignal support as well as issues with RX desensitized after strong CW TX. I am not quite sure of the best way to expose this to software, and would like your input. Here are some options I am considering.
1. Don't have a separate TX gain in the gateware. Instead, software should always manage this. The changes I've made just mean that LNA gain updates requested by software will happen with less latency. Some software doesn't manage two gain settings, for example Quisk, and it would be nice to update this software to support separate RX and TX LNA gain settings.
2. Use the "ADC Input Attenuator TX" (0-31dB) 4-bits of C3 when C0==0001110x in the current protocol 1. There are extra bits in this byte to support the same LNA scheme we use for the current global RX LNA gain setting. But I don't see a way to turn this on or off, and am not sure how it will interact or fight with software that is also trying to manage the LNA gain during TX.
3. Same as 2, but assign the last remaining free bit in C3 to be on or off for hardware-based TX gain management. This way software has control. The default would be off for software managed TX gain. Software would have to purposefully set this value and enable hardware-based TX gain management.
73,
Steve
kf7o
Alan Hopper
Mar 17, 2020, 7:49:51 AM3/17/20
to Hermes-Lite
Hi Steve,
This all sounds good.
As far as I can tell powersdr does not use the 'ADC Input Attenuator TX' bits and from looking at it in my emulator just changes the rx attenuator value on rx. Option 3 looks the the best to me. I do think doing this in hardware is a good thing, at the point ptt changes the software tries to set a number of things and there is competition for which cc packet to send, currently I send filter and lna in the two chunks that go in the packet that also has the ptt change. Another related issue is I don't know which gain applies to the received packets around the change.
73 Alan M0NNB
Matthew
Mar 17, 2020, 3:07:55 PM3/17/20
to Hermes-Lite
Option 3 sounds best to me too.
73 Matthew M5EVT.
James Ahlstrom
Mar 18, 2020, 9:51:19 AM3/18/20
to Hermes-Lite
Hello Steve, Allan, Matthew,
I generally dislike options because they offer an opportunity to set them wrong, but for reasons given by Alan, I also think 3 is best. So to be clear, (C0==0001110x ; C3) has the same format as (C0==00001010x ; C4) except that bit C3[7] enables C3 as the LNA gain for Tx. Right?
Jim
N2ADR
Steve Haynal
Mar 19, 2020, 2:20:31 AM3/19/20
to Hermes-Lite
Hi Jim,
Yes, that is correct. I've updated the protocol wiki page with this:
| 0x0e | [7] | Enable hardware managed LNA gain for TX |
| 0x0e | [6] | See LNA gain section below |
| 0x0e | [5:0] | LNA[5:0] gain during TX if enabled |
Bits [6:0] will be treated exactly as the existing LNA. Bit[7] is the enable.
73,
Steve
kf7o
James Ahlstrom
Mar 20, 2020, 4:15:01 PM3/20/20
to Hermes-Lite
Hello Steve,
I think the indexes should be [15], [14], [13:8] for C3. If you agree, I can change the wiki if you want.
Jim
N2ADR
Steve Haynal
Mar 21, 2020, 1:45:09 AM3/21/20
to Hermes-Lite
Hi Jim,
Sorry about that, you are correct. I've updated the wiki.
73,
Steve
kf7o
Matthew
Apr 13, 2020, 9:02:24 AM4/13/20
to Hermes-Lite
Hi Steve,
I gave my setup a good test over the weekend making around 150 qsos to test my linhpsdr(cwx+cwdaemon)+HL2(gateware 20200329_70p0) setup in the weekend's cw contest. I've found a few software niggles to work on for linhpsdr.
I was keeping a close eye on my command line debugging for linhpsdr. Early in the contest I noticed some HL2 TX buffer issues with break-in keying. To be safe, I decided to increase the CW hang time (around 400 ms @ 30 wpm). However, because of this I was missing the start of some exchanges and when some people mistake me for W5 instead of M5, I need to hear that first character! I have been looking at this today.
I've read your post below a couple of times and feel I have got to grips with the detail. I have the latency set for 21 ms. The following debug is all based on reading control bits straight from the HL2 packet (1 rx @ 48000, I confirm in wireshark rx:tx packet ratio is always 1:1):
C[3] = 0x8f Buffer recovery 0 1
C[3] = 0x1f
process_control_bytes: ppt=1 dot=0 dash=0
C[3] = 0x2f
C[3] = 0x3d
C[3] = 0x3d
C[3] = 0x3d
...
C[3] = 0x3d
process_control_bytes: ppt=0 dot=0 dash=0
C[3] = 0x3d
C[3] = 0x3d
C[3] = 0x3d
C[3] = 0x3d
C[3] = 0x46
C[3] = 0x56
C[3] = 0x66
process_control_bytes: ppt=1 dot=0 dash=0
C[3] = 0x76
C[3] = 0xf8 Buffer recovery 1 1
C[3] = 0xe9 Buffer recovery 1 1
C[3] = 0xd9 Buffer recovery 1 1
C[3] = 0xc9 Buffer recovery 1 1
C[3] = 0xb9 Buffer recovery 0 1
C[3] = 0xaa Buffer recovery 0 1
C[3] = 0x9a Buffer recovery 0 1
C[3] = 0x9a Buffer recovery 0 1
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
...
C[3] = 0x1a
process_control_bytes: ppt=0 dot=0 dash=0
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1f
C[3] = 0x2f
C[3] = 0x3e
process_control_bytes: ppt=1 dot=0 dash=0
C[3] = 0x4e
C[3] = 0x57
C[3] = 0x57
C[3] = 0x57
C[3] = 0x57
C[3] = 0x57
Note, PTT is off and the latency increases before the PTT comes back on (cwx bit set in TX packet). Our TX buffer level is now 0x57.
In the following condition, the FIFO stable at C[3] = 0x1f before PTT=0:
C[3] = 0x1f
C[3] = 0x1f
process_control_bytes: ppt=0 dot=0 dash=0
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x17
C[3] = 0x7
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x17
C[3] = 0x7
C[3] = 0x80 Buffer recovery 0 1
C[3] = 0x80 Buffer recovery 0 1
I was trying to figure out if I could detect the latency changes based on knowing when I sent the TX packet and when the TX is keyed. However, I couldn't figure out how in any of the information I get back from the HL2, that the TX is keyed (rather than PTT engaged). Perhaps this is to avoid breaking PowerSDR? (I don't really think this information is useful beyond for debugging?)
I hope this is clear. Am I doing something wrong in my configuration bits I am sending or is this a feature (i.e. just ignore this warning?) or a bug?
I gave my setup a good test over the weekend making around 150 qsos to test my linhpsdr(cwx+cwdaemon)+HL2(gateware 20200329_70p0) setup in the weekend's cw contest. I've found a few software niggles to work on for linhpsdr.
I was keeping a close eye on my command line debugging for linhpsdr. Early in the contest I noticed some HL2 TX buffer issues with break-in keying. To be safe, I decided to increase the CW hang time (around 400 ms @ 30 wpm). However, because of this I was missing the start of some exchanges and when some people mistake me for W5 instead of M5, I need to hear that first character! I have been looking at this today.
I've read your post below a couple of times and feel I have got to grips with the detail. I have the latency set for 21 ms. The following debug is all based on reading control bits straight from the HL2 packet (1 rx @ 48000, I confirm in wireshark rx:tx packet ratio is always 1:1):
C[3] = 0x8f Buffer recovery 0 1
C[3] = 0x1f
process_control_bytes: ppt=1 dot=0 dash=0
C[3] = 0x2f
C[3] = 0x3d
C[3] = 0x3d
C[3] = 0x3d
...
C[3] = 0x3d
process_control_bytes: ppt=0 dot=0 dash=0
C[3] = 0x3d
C[3] = 0x3d
C[3] = 0x3d
C[3] = 0x3d
C[3] = 0x46
C[3] = 0x56
C[3] = 0x66
process_control_bytes: ppt=1 dot=0 dash=0
C[3] = 0x76
C[3] = 0xf8 Buffer recovery 1 1
C[3] = 0xe9 Buffer recovery 1 1
C[3] = 0xd9 Buffer recovery 1 1
C[3] = 0xc9 Buffer recovery 1 1
C[3] = 0xb9 Buffer recovery 0 1
C[3] = 0xaa Buffer recovery 0 1
C[3] = 0x9a Buffer recovery 0 1
C[3] = 0x9a Buffer recovery 0 1
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
...
C[3] = 0x1a
process_control_bytes: ppt=0 dot=0 dash=0
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1a
C[3] = 0x1f
C[3] = 0x2f
C[3] = 0x3e
process_control_bytes: ppt=1 dot=0 dash=0
C[3] = 0x4e
C[3] = 0x57
C[3] = 0x57
C[3] = 0x57
C[3] = 0x57
C[3] = 0x57
Note, PTT is off and the latency increases before the PTT comes back on (cwx bit set in TX packet). Our TX buffer level is now 0x57.
In the following condition, the FIFO stable at C[3] = 0x1f before PTT=0:
C[3] = 0x1f
C[3] = 0x1f
process_control_bytes: ppt=0 dot=0 dash=0
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x17
C[3] = 0x7
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x1f
C[3] = 0x17
C[3] = 0x7
C[3] = 0x80 Buffer recovery 0 1
C[3] = 0x80 Buffer recovery 0 1
I was trying to figure out if I could detect the latency changes based on knowing when I sent the TX packet and when the TX is keyed. However, I couldn't figure out how in any of the information I get back from the HL2, that the TX is keyed (rather than PTT engaged). Perhaps this is to avoid breaking PowerSDR? (I don't really think this information is useful beyond for debugging?)
I hope this is clear. Am I doing something wrong in my configuration bits I am sending or is this a feature (i.e. just ignore this warning?) or a bug?
73 Matthew M5EVT.
Steve Haynal
Apr 16, 2020, 1:34:02 AM4/16/20
to Hermes-Lite
Hi Matthew,
Sorry for the late reply. I am going to punt on this one for a few more days. It is late and I'm not thinking straight. Also, work has been very busy even though I am now working from home.
73,
Steve
kf7o
Matthew
Apr 16, 2020, 6:14:53 AM4/16/20
to Hermes-Lite
No problem at all Steve - no rush. I'm adapting to being a home schooling teacher and trying to work from home, so I understand.
73 Matthew M5EVT.
Steve Haynal
Apr 18, 2020, 10:35:22 PM4/18/20
to Hermes-Lite
Hi Matthew,
I'm not sure I understand everything happening on the software side, but I'll try to provide more details on the gateware side. When you say RX:TX ratio is 1:1, does that mean LinHPSDR is no longer sending 8 ~1024-byte packets all at once? Here is the sequence of events in the gateware when CWX true is detected:
1. NOTX:
PTT return is 0
TX is off
TX buffer emptying is True
The gateware waits for a mox or cwx request from software, or an external cw key event. If one of these events occurs, gateware goes to state 2. PRETX.
The gateware idles in this state, but is emptying the buffer at the correct rate. Any garbage in the TX buffer is emptied. The purpose here is to drain the buffer to 0 when no transmit.
2. PRETX
PTT return is 0
TX is on but zeros sent, this is to enable all relays at least 6ms before true signal
TX buffer emptying is False
The gateware remains in this state for tx_buffer_latency ms. The default tx_buffer_latency is 10ms. The FIFO will fill because it is not emptying during this period. This is the filling you see before PTT becomes 1. The point is to fill it by tx_buffer_latency worth of samples. Note that it can fill by more if software sends more samples or multiple UDPs worth samples. Once the wait is over (there are some early exits if the TX reason becomes false), the gateware proceeds to state 3. CWXTX
3. CWXTX
PTT return is 1
TX is on and real data is sent
TX buffer emptying is True
In this state, the gateware ramps the CW TX signal from 0 to max in 4ms. The shape is a linear ramp up. Data is pulled from the TX buffer at the expected rate. If CWX becomes false, then the signal is ramped down to 0 in 4ms if it had achieved full strength. Otherwise, the ramp up to some half strength value could be 2ms and then ramp down 2ms, etc., if the CWX signal was on only briefly. The gateware proceeds to state 4. CWXHANG.
4. CWXHANG
PTT return is 0
TX is on but zeros sent, to prevent the penalty of relays disengaging/engaging
TX buffer emptying is True
The gateware stays in this state for the duration specified by cw_hang_time. The default cw_hang_time is 0ms. The purpose of hang time is to continue with TX for the next CW dot/dash without disengaging/reengaging the relays and paying that penalty. If the next CWX true occurs before the end of cw_hang_time, then the gateware returns to state 3. CWXTX. If cw_hang_time expires, the gateware returns to state 1. NOTX.
Note that in the above sequence, all states pull data from the TX buffer at the expected rate except PRETX. That is the state that waits and allows the buffer to fill by tx_buffer_latency. The intent is that the TX buffer level will always be 0 or near 0 when entering PRETX, but after writing this post I think there is a bug where NOTX should be emptying the buffer at a fast rate, not the expected rate. This could cause the accumulation of data in the TX buffer that you are seeing. I will fix that and release gateware soon. I'll still make this post as it is already written my be interesting to some.
73,
Steve
kf7o
Matthew
Apr 19, 2020, 11:17:42 AM4/19/20
to Hermes-Lite
Thanks for the detailed reply. I modified linHPSDR so that the 1024 byte packets sent from linHPSDR are synchronised to packets received from the HL2 (sent to EP6). This is now in the main branch on John's github. TX packets are scheduled based upon sample rate and number of receivers. I used the fine work done by N5EG:
I believe this is what Quisk and SparkSDR also do internally. The result is much more reliable transmit audio for a wider variety of computer systems.
It is going to take me a few days to digest your reply, draw some diagrams and cross check my understanding by observing the behaviour in my code. I was surprised that in state CWXHANG the PTT return is 0. When I set a long cw_hang_time, I hear a relay click after cw_hang_time milliseconds. I assume this is relay K2 controlled by INTTR? My natural assumption interpreting these bits in software would be if I saw PTT 0, that the relay was back to receive? I will need to check this has no undesired behaviour in linHPSDR if I have assumed this.
If you want any verbose outputs from linhpsdr to help with debugging this, let me know and I can send you a patch.
73 Matthew M5EVT.
Steve Haynal
Apr 21, 2020, 12:53:41 AM4/21/20
to Hermes-Lite
Hi Matthew,
Plesae try the new 20200420_71p0 testing release and let me konw if this makes any difference with you problem. There was a bug that only mattered for CWX and the TX buffer which was fixed.
73,
Steve
kf7o
Matthew
Apr 21, 2020, 4:36:36 PM4/21/20
to Hermes-Lite
Hi Steve,
I have spent a few hours on this but I'm out of time for tonight. As far as I can tell, the problem I described in my original post is fixed in this new gateware. What I am now noticing is that sometimes the first dit is chopped off from a transmission. For example, the HL2 is in state NOTX, I send via CWX (in linHPSDR) an "i", at 30-32 wpm (not that it matters, but I have break in set to 150 ms for my tests). Instead of an "i", I am sending an "e" over the air. I was paranoid I was doing something wrong, but I have confirmed in wireshark that I definitely send the 2 dits with the correct timing. Additionally, to eliminate any potential bug in my code, I confirm this behaviour in PowerSDR too using the CWX keyboard macros.
I have saved all my wireshark data and will do more digging in some more evenings this week. I will also spend some more time looking at the TX state machine in radio.v to see if (with my rusty verilog) I can see what might be causing this.
If CWX proves to be too much bother to support/maintain I'm not at all against implementing the method Alan and Jim have adopted by sending the CW waveform in IQ packets to the HL2. I know we have this feature for PowerSDR but I'm not sure anyone has confirmed that serial port keying works in the PowerSDR version that works with the HL2. I couldn't get it to work in Wine, but I think that was a Wine/serial port issue. If this is indeed a PowerSDR bug, perhaps someone could be persuaded to look at this and it might be an easy fix?
73 Matthew M5EVT.
Steve Haynal
Apr 21, 2020, 11:55:47 PM4/21/20
to Hermes-Lite
Hi Matthew,
Thanks for the report. I need to think about this. To keep things interesting for me, I am trying to do the CWX implementation differently from the original openhpsdr code. I must not have it quite right yet. I do want to have CWX fully working.
73,
Steve
kf7o
Reply all
Reply to author
Forward
0 new messages