RNode serial communication strangeness.

[faragher]

I'm trying to get a serial command system for RNode testing. I'm getting some strange results from C#, and I'm not sure if it's my code, the ESP32, the firmware, or a serial error. This is my terminal session:

Reset Detected
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13160
load:0x40080400,len:3036
entry 0x400805e4

RNode Reset Detected
C0 FEND
55 CMD_RESET
F8 Undefined
C0 FEND
f 915200000
915200000
36 8C D8 00
C0 FEND
01 CMD_FREQUENCY
36 Undefined
8C Undefined
00 CMD_DATA
00 CMD_DATA
C0 FEND
b 125000
125000
00 01 E8 48
C0 FEND
02 CMD_BANDWIDTH
00 CMD_DATA
01 CMD_FREQUENCY
00 CMD_DATA
00 CMD_DATA
C0 FEND
s 8
C0 FEND
04 CMD_SF
08 CMD_DETECT
C0 FEND
t 4
C0 FEND
03 CMD_TXPOWER
04 CMD_SF
C0 FEND
c 5
C0 FEND
05 CMD_CR
05 CMD_CR
C0 FEND
u
C0 FEND
06 CMD_RADIO_STATE
01 CMD_FREQUENCY
C0 FEND
C0 FEND
06 CMD_RADIO_STATE
01 CMD_FREQUENCY
C0 FEND

C0 FEND
08 CMD_DETECT
46 DETECT_RESP
C0 FEND
C0 FEND
50 CMD_FW_VERSION
01 CMD_FREQUENCY
3D Undefined
C0 FEND
C0 FEND
48 CMD_PLATFORM
80 Undefined
C0 FEND
C0 FEND
49 CMD_MCU
81 Undefined
C0 FEND
d
C0 FEND
06 CMD_RADIO_STATE
00 CMD_DATA
C0 FEND

Here's the important bits, remembering this is a slap-dash tool I made for personal use:

f 915200000 <- input, Frequency 915.2 MHz
915200000 <- echo, ulong with value 915200000
36 8C D8 00 <- hex representation of value, this is correct
C0 FEND <- Begin response, frame end
01 CMD_FREQUENCY 
36 Undefined <- actually raw data, ignore the command code
8C Undefined <- actually raw data, ignore the command code
00 CMD_DATA <- actually raw data, ignore the command code
00 CMD_DATA <- actually raw data, ignore the command code
C0 FEND <- End response, frame end

This returns 36 8C 00 00 instead of 36 8C D8 00, or 915,144,704 instead of 915,200,000. There is a similar error in the bandwidth system.

b 125000
125000
00 01 E8 48
C0 FEND
02 CMD_BANDWIDTH
00 CMD_DATA
01 CMD_FREQUENCY
00 CMD_DATA
00 CMD_DATA
C0 FEND

Same issue, returning 00 01 00 00 instead of 00 01 E8 48 . It's suspicious in both cases that the lower two bytes are zero.

However:

u
C0 FEND
06 CMD_RADIO_STATE
01 CMD_FREQUENCY
C0 FEND

The radio comes up correctly, and the waterfall functions correctly. This confuses me in a few ways.

Does anyone familiar with the firmware or serial control mechanisms have any thoughts on where the error lies or any good ways forward?

[markqvist]

Is this happening on firmware compiled from the source repo, or installed from the binary releases?

[faragher]

1.61 as installed by rnodeconf.

[markqvist]

Good, just wanted to check it wasn't something introduced in all the latest additions to the code. I'll have a look at it, it's definitely very strange!

[faragher]

I'm having a lot of Windows issues right now. I think that's the root of a lot of it. I'll try sending this over to a Linux system, but I don't think any of my current test systems have Mono. I'll be a hot second.

Anyway, hooked up the SDR, and it seems to broadcast correctly (proper center frequency, actually exceptionally accurate, correct bandwidth, etc.). However I get maybe one or two announces before I get major problems in Sideband (which works on Windows? That surprised me) and rnsd --verbose shows that it's having the same problems, just failing gracefully.

[2024-02-14 04:14:59] [Verbose] Bringing up system interfaces...
[2024-02-14 04:14:59] [Notice] Opening serial port COM7...
[2024-02-14 04:15:01] [Notice] Serial port COM7 is now open
[2024-02-14 04:15:01] [Verbose] Configuring RNode interface...
[2024-02-14 04:15:01] [Verbose] Waiting for radio configuration validation for R
NodeInterface[RNode LoRa Interface]...
[2024-02-14 04:15:01] [Error] Bandwidth mismatch
[2024-02-14 04:15:01] [Error] TX power mismatch
[2024-02-14 04:15:01] [Error] Spreading factor mismatch
[2024-02-14 04:15:01] [Error] Radio state mismatch
[2024-02-14 04:15:01] [Error] After configuring RNodeInterface[RNode LoRa Interf
ace], the reported radio parameters did not match your configuration.
[2024-02-14 04:15:01] [Error] Make sure that your hardware actually supports the
 parameters specified in the configuration
[2024-02-14 04:15:01] [Error] Aborting RNode startup

This is exactly the issue I had with my C# RNode Interface. It would fail out with the lowest two bites being unset. It usually came up on a warm boot but not a cold one. Since it's happening ion the reference implementation, I think we can rule out my implementation and C#. I'll do a Linux Python test just to make sure, then move on to Linux C#.

[2024-02-14 04:15:01] [Verbose] System interfaces are ready
[2024-02-14 04:15:01] [Verbose] Configuration loaded from C:\Users\Michael/.reti
culum/config
[2024-02-14 04:15:01] [Verbose] Loaded 123 known destination from storage
[2024-02-14 04:15:01] [Verbose] Loaded Transport Identity from storage
[2024-02-14 04:15:01] [Notice] Started rnsd version 0.7.0
[2024-02-14 04:15:06] [Verbose] Attempting to reconnect serial port COM7 for RNo
deInterface[RNode LoRa Interface]...
[2024-02-14 04:15:06] [Notice] Opening serial port COM7...
[2024-02-14 04:15:06] [Error] An interface error occurred, the contained excepti
on was: [WinError 10054] An existing connection was forcibly closed by the remot
e host
[2024-02-14 04:15:06] [Error] Tearing down LocalInterface[6503]
[2024-02-14 04:15:06] [Error] The interface LocalInterface[6503] experienced an
unrecoverable error and is being torn down. Restart Reticulum to attempt to open
 this interface again.
[2024-02-14 04:15:08] [Notice] Serial port COM7 is now open
[2024-02-14 04:15:08] [Verbose] Configuring RNode interface...
[2024-02-14 04:15:08] [Verbose] Waiting for radio configuration validation for R
NodeInterface[RNode LoRa Interface]...
[2024-02-14 04:15:08] [Verbose] RNodeInterface[RNode LoRa Interface] On-air bitr
ate is now 3.12 kbps
[2024-02-14 04:15:09] [Notice] RNodeInterface[RNode LoRa Interface] is configure
d and powered up
[2024-02-14 04:15:09] [Notice] Reconnected serial port for RNodeInterface[RNode
LoRa Interface]

It doesn't help that I can't reliably reproduce this issue. It seems that the Python implementation seems to work through reboots, etc. after the first failure of the . . . whatever. Even through power cycles. I need to write a test transmission routine, then will report back.

[faragher]

Yup. Looks like the bandwidth autocorrects to 250k or 125k but center frequency is at ~915.138 MHz, so it looks like the readback of the registers is correct.

However, to have this make even less sense, if I change the frequency or BW while the radio is up, the bandwidth does exactly what I tell it to do, and the frequency goes to 915MHz, but refuses to go to 915.2. In fact it snaps from .144 (request .200) to .275 (request ,280).

Am I missing a register for fine frequency control or something? That would explain some of this, but not why it needs to be configured to be brought up, then needs to be reconfigured while up.

[faragher]

C# has the same issues in Linux. Although I get a LOT more data on the serial lines in Linux. Windows is basically silent. I'm getting a lot of undefined codes in Linux. (FEND, 0x27, some data, FEND. Also some what looks like eight byte wide 0x00s with FENDS and maybe a control byte I forgot)

Edit: Ah, 0x27 is battery. I must have enabled the battery meter on that board.

0x25 byte[8] - CMD_STAT_CHTM. Channel stats. Why isn't this streamed to Windows? Configuration or something else?

[faragher]

Python serial control appears to work as expected. I'll check my code, but I'm beginning to think it's the .net serial protocols.

[faragher]

sigh

Wrote:

    for (int i = 2; i < data.Count; i++)

Meant:

    for (int i = 2; i < data.Count+2; i++)

Situation resolved. PEBCAK.

[markqvist]

Hah, that's how it goes sometimes :) Good to know it wasn't something very strange in the firmware.