markqvist / rnode_firmware Goto Github PK

2 x LilyGO LoRa32 v2.1 (aka T3 v1.6.1) running 1.55 firmware
2 x Arch Linux Computers

Hello Mark,

When in TNC mode with both nodes configured identically, the units are unable to communicate with each other. If the antennas are replaced with a direct wire, communication is able to occur and I am able to ping across the LoRa nodes. I can verify that this activity is happening by using tncattach in verbose mode.

Here are the commands being ran:
rnodeconf /dev/ttyACM0 -T --freq 915000000 --bw 500000 --txp 17 --sf 12 --cr 7
sudo tncattach /dev/ttyACM0 115200 --mtu 496 --noipv6 --noup -v

When the exact same configuration is used in reticulum, everything works as intended. I am able to use nomadnet to exchange messages over the LoRa nodes without a problem.

If you need any supporting logs or further documentation, please feel free to let me know.

Thanks in advance.

Hi 👋

Im tryng to setup the RGB Led, im using a breakout ws812 and a Heltec 32 v2.

Cheking the config.h (https://github.com/markqvist/RNode_Firmware/blob/1.57/Config.h) and the guide (step 7 https://unsigned.io/guides/2023_01_14_Making_A_Handheld_RNode.html ) I see that the io pin for the data in the board is other than the IO12 Right? 25 (internal) or 36/37 (for external).

Im getting that right? (Try all of them and the RGB is still off. RGB works since touching Data with the finger (i know.. i know...) the led starts. Tested both 3.5 and 5v since the led is 5v. Same.

Try it with 1.56 and 1.57.

Reference: https://escapequotes.net/wp-content/uploads/2021/02/WIFI_LoRa_32_V2-Heltec-pinout-diagram-scaled.jpg

Led: https://www.digikey.com/htmldatasheets/production/1960378/0/0/1/ws2812-breakout-hookup-guide.html

is possible to know what im doing wrong ? :(

Hi Mark, please allow me to give you the praise that you deserve before asking for support while I try to join the TRUE internet, the RetNet :-)

I stumbled upon your work about a week ago, realizing the incredible potential. You are a truly visionary man with extraordinary capabilities and exceptional perseverance. A great example for the rest of us! Let's carry on ... with my little problem :-)

I get a warning message when I try to install the RNode firmware v1.56 on a LilyGO LoRa32 v2.1 (T3 v1.6.1) 868 Mhz board:

WARNING: Detected crystal freq 41.01MHz is quite different to normalized freq 40MHz. Unsupported crystal in use?

A fatal error occurred: Failed to write to target RAM (result was 01070000)

                               Installer Ready

Ok, that should be all the information we need. Please confirm the following
summary before proceeding. In the next step, the device will be flashed and
provisioned, so make sure that you are satisfied with your choices.

Serial port     : /dev/cu.usbmodem53230228381
Device type     : LilyGO LoRa32 v2.1 850 - 950 MHz
Platform        : ESP32
Device MCU      : Espressif Systems ESP32
Firmware file   : rnode_firmware_lora32v21.zip

------------------------------------------------------------------------------

Is the above correct? [y/N] y
[11:55:00] Checking firmware file availability...
[11:55:00] The latest firmware for this board is version 1.56
[11:55:00] Using existing firmware file: rnode_firmware_lora32v21.zip for version 1.56
[11:55:00] Verifying firmware integrity...
[11:55:00] Decompressing firmware...
Archive:  /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.zip
  inflating: /Users/username/.config/rnodeconf/update/1.56/esptool.py  
  inflating: /Users/username/.config/rnodeconf/update/1.56/console_image.bin  
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.boot_app0  
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.bin  
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.bootloader  
  inflating: /Users/username/.config/rnodeconf/update/1.56/rnode_firmware_lora32v21.partitions  
[11:55:00] Firmware decompressed
[11:55:00] Flashing RNode firmware to device on /dev/cu.usbmodem53230228381
esptool.py v3.1
Serial port /dev/cu.usbmodem53230228381
Connecting....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
WARNING: Detected crystal freq 41.01MHz is quite different to normalized freq 40MHz. Unsupported crystal in use?
Crystal is 40MHz
MAC: 4c:75:25:c2:f2:58
Uploading stub...

A fatal error occurred: Failed to write to target RAM (result was 01070000)
username@usernames-macbook ~ % 

Board is marked 20210104. New FCC tag, some updated components, but appears identical to old version excepting LoRa module. I'll check to see if they have updated datasheets.

The firmware is much chattier on the serial line, but that might be from recent updates (1.61 to 1.69)

Serial output (hand modified for clarity) follows:

// kiss_indicate_phy_stats - 3x
C0 FEND
26 CMD_STAT_PHYPRM
04 LoRa Symbol Time
00 LoRa Symbol Time
03 LoRa Symbol Rate
D0 LoRa Symbol Rate
00 LoRa Preamble Symbols
16 LoRa Preamble Symbols
00 Preamble Time?
16 Preamble Time?
00 CSMA slot
32 CSMA slot
C0 FEND


// Radio is up
C0 FEND
06 CMD_RADIO_STATE
01 CMD_FREQUENCY
C0 FEND

// It always seems to repeat itself
C0 FEND
06 CMD_RADIO_STATE
01 CMD_FREQUENCY
C0 FEND


// kiss_indicate_channel_stats 5x
C0 FEND
25 CND_STAT_CHTM
00 Airtime
00 Airtime
00 Longterm Airtime
00 Longterm Airtime
00 Channel Utilization
00 Channel Utilization
00 Long Term Channel Utilization
00 Long Term Channel Utilization
C0 FEND

Radio reports up, but shows no waterfall and repeats channel data 1-2 times per second. Red and blue LEDs active, green off. On attempted transmit, green LEDs illuminates brightly and is steady on, RNode appears to freeze entirely at this time. No further serial communication is sent.

Detect seems to perform as expected:

C0 FEND
08 CMD_DETECT
46 DETECT_RESP
C0 FEND
C0 FEND
50 CMD_FW_VERSION
01 1
45 69
C0 FEND
C0 FEND
48 CMD_PLATFORM
80 PLATFORM_ESP32
C0 FEND
C0 FEND
49 CMD_MCU
81 MCU_ESP32
C0 FEND

It thinks it initializes correctly, but the waterfall display doesn't function, which gives a place to start digging. I'm going to check data sheets first, since this might be more obvious to someone more familiar with the firmware.

Describe the Bug

In a simple lora mesh scenario with 3 nodes where one node is acting as a transport node between the other two, a nomadnet client is unable to successfully retrieve a page from a nomadnet server over the transport node.

To Reproduce

In this topology, node A and node C are not within direct range of each other, but both are within direct range of node B which is operating as a transport node.

1. Clear destinations and launch rnsd on node A (nomadnet client node)
2. Clear destinations and launch rnsd on node B (transport node)
3. Clear destinations and launch rnsd on node C (nomadnet server node)
4. Confirm through rnpath that node A has a route to node C (2 hops via node B)
5. Confirm through rnprobe that node C responds to probe requests from node A
6. Launch nomadnet on node A and wait for radio activity to settle
7. Launch nomadnet on node C and wait for radio activity to settle
8. Attempt to connect nomadnet client on node A to nomadnet server running on node C
9. Observe that link is established (most of the time) but page transfer (706 bytes) hangs indefinitely at 50% progress

Expected Behavior

• Node A should be able to successfully receive a small file (706 bytes) sent by node C via transport node B.
• CSMA in RNode of nodes A and B should be able to coordinate their transmissions so as not to interfere with each other since they are within direct range of one another.

Logs & Screenshots

Node A RNS:

[2024-03-10 14:54:37] [Extra] Filtered packet with hash <f9b94589798d4ccc294c05f8db5250dd4f433ce6a14eee8f79dcbdec4d7fce31>
[2024-03-10 14:54:38] [Extra] Link request proof validated for transport via LocalInterface[61210]
[2024-03-10 14:54:39] [Extra] Valid announce for <2b9129e4a711eec591b20b23af9c0c2e> 2 hops away, received via <86d3792a7dede793babe75de722aa6e8> on RNodeInterface[RNode LoRa Interface] [RSSI -99dBm, SNR 9.75dB]
[2024-03-10 14:54:39] [Debug] Destination <2b9129e4a711eec591b20b23af9c0c2e> is now 2 hops away via <86d3792a7dede793babe75de722aa6e8> on RNodeInterface[RNode LoRa Interface]
[2024-03-10 14:54:40] [Debug] Rebroadcasting announce for <2b9129e4a711eec591b20b23af9c0c2e> with hop count 2
[2024-03-10 14:54:40] [Extra] Added announce to queue (height 1) on RNodeInterface[RNode LoRa Interface] for processing in 24.73s
[2024-03-10 14:54:41] [Extra] Filtered packet with hash <8ebcdb15bf77320c06f09f79a69c61b575139e747cca43a3c3ef6719fb2d837d>
[2024-03-10 14:54:42] [Extra] Filtered packet with hash <f2304cab3f6e6f80768ec157ad74bfd82f8d5718e88ed8bf14db87755362e3e0>
[2024-03-10 14:54:42] [Extra] Filtered packet with hash <6820a9744d04f0c2af3cc18b35b8528e82581184471c52ece9762883ca178902>
[2024-03-10 14:54:46] [Debug] Rebroadcasting announce for <2b9129e4a711eec591b20b23af9c0c2e> with hop count 2
[2024-03-10 14:54:47] [Extra] Completed announce processing for <2b9129e4a711eec591b20b23af9c0c2e>, retry limit reached
[2024-03-10 14:55:56] [Extra] Filtered packet with hash <6cefff781298f657b8f5f8e3c00f759517f46c48aa387382c67beac52c31e289>
[2024-03-10 14:56:11] [Debug] Trying to rediscover path for <2b9129e4a711eec591b20b23af9c0c2e> since an attempted local client link was never established
[2024-03-10 14:56:11] [Extra] Released 1 link
[2024-03-10 14:56:15] [Extra] Valid announce for <2b9129e4a711eec591b20b23af9c0c2e> 2 hops away, received via <86d3792a7dede793babe75de722aa6e8> on RNodeInterface[RNode LoRa Interface] [RSSI -92dBm, SNR 11.75dB]

Node B RNS:

[2024-03-10 14:54:38] [Extra] Link request proof validated for transport via RNodeInterface[RNode LoRa Interface]
[2024-03-10 14:54:42] [Extra] Valid announce for <cbb023fff1a06352d210030eb91412d2> 3 hops away, received via <d2db5a15a5a1a9efd612cbb6b0130bb4> on RNodeInterface[RNode LoRa Interface] [RSSI -98dBm, SNR 11.75dB]
[2024-03-10 14:55:06] [Extra] Valid announce for <2b9129e4a711eec591b20b23af9c0c2e> 3 hops away, received via <d2db5a15a5a1a9efd612cbb6b0130bb4> on RNodeInterface[RNode LoRa Interface] [RSSI -89dBm, SNR 9.5dB]
[2024-03-10 14:56:06] [Debug] Trying to rediscover path for <2b9129e4a711eec591b20b23af9c0c2e> since an attempted link was never established, and destination was previously local to an interface on this instance
[2024-03-10 14:56:06] [Extra] Released 1 link
[2024-03-10 14:56:11] [Debug] Path request for <2b9129e4a711eec591b20b23af9c0c2e> on RNodeInterface[RNode LoRa Interface]
[2024-03-10 14:56:11] [Debug] Answering path request for <2b9129e4a711eec591b20b23af9c0c2e> on RNodeInterface[RNode LoRa Interface], path is known
[2024-03-10 14:56:12] [Debug] Rebroadcasting announce as path response for <2b9129e4a711eec591b20b23af9c0c2e> with hop count 1
[2024-03-10 14:56:13] [Extra] Completed announce processing for <2b9129e4a711eec591b20b23af9c0c2e>, retry limit reached

Node C RNS:

[2024-03-10 20:54:38] [Extra] Link request proof validated for transport via RNodeInterface[RNode LoRa Interface]
[2024-03-10 20:54:39] [Extra] Filtered packet with hash <c48e2071844960e011696a33388c790b52a1290579b1ca53100a3543c280821a>
[2024-03-10 20:54:40] [Extra] Valid announce for <2b9129e4a711eec591b20b23af9c0c2e> 2 hops away, received via <86d3792a7dede793babe75de722aa6e8> on RNodeInterface[RNode LoRa Interface] [RSSI -106dBm, SNR -3.0dB]
[2024-03-10 20:55:56] [Extra] Link request proof validated for transport via RNodeInterface[RNode LoRa Interface]
[2024-03-10 20:56:15] [Extra] Valid announce for <2b9129e4a711eec591b20b23af9c0c2e> 2 hops away, received via <86d3792a7dede793babe75de722aa6e8> on RNodeInterface[RNode LoRa Interface] [RSSI -107dBm, SNR 4.0dB]

Below is an annotated SDR screenshot demonstrating this scenario. Note that in the annotations the term "repeater" and "repeated" is used as a generalization for transport node and packets that are relayed by the transport node.

System Information

• macOS Ventura 13.6.3 & Debian GNU/Linux 12
• Python 3.11.5
• RNS 0.7.3 & RNode 1.7.0

The error affects several users and can be exactly reproduced.
All details and already performed test scenarios can be found in the discussion.

I hope that Mark will find time to look at this problem.

Thanks

Originally posted by @SebastianObi in markqvist/Reticulum#327

Hello Mark.
I am interested to compile RNode firmware with E22-400M30S based on SX1268 433/470MHz SPI SMD LoRa Module
on generic ESP32 board

E22-400M30S_UserManual_EN_v1.3.pdf

Thanks.

I have used RNode as a TNC for APRS, I use also T-beam v1 with SQ9MDD sot. TNC.
I found the packets from both TNCs are incompatible to each other. Moreover, RNode's packets are incompatible with other aprs over LoRa projects too.

The aprs frame sent by Xastir via RNode TNC
[2022-12-18 20:25:08] [-23 dBm] [SNR 10.75 dB] [45 bytes]
b'\xa0\x82\xa0\xb0dbp\x9a\x92\x8e\x82@`\xae\x92\x88\x8ad@e\x03\xf0=5452.39N\00121.80Wz\r'

The aprs frame sent by Xastir via SQ9MDD TNC
[2022-12-18 20:25:37] [-24 dBm] [SNR 13.5 dB] [45 bytes]
b'<\xff\x01M0IGA>APX218,WIDE2-2:=5452.39N\00121.80Wz\r'

Why these are different and which one is correct?

Describe the Bug
When attempting to send a message through an RNode device (Lilygo T-beam 433MHz SX1278 firmware 1.7) using the Sideband app on android, messages always fail to send going from "Establishing link" to "waiting for path" to "failed". This is evidenced by the fact that my two test devices will begin transmitting simultaneously as seen by the red LED indicator.

To Reproduce
Connect two RNode devices with sideband (at least one using the android client). After announcements, attempt to send a message from a device using the android app. The message will fail.

Expected Behavior
Sending a message from the android app should complete successfully.

Logs & Screenshots
I don't know how to get to log output from Android, I can dump a PC side log.

System Information

• Android 13/Ubuntu 22.04
• Python 3.9
• 0.8.1, 0.8.0, 0.7.9 affected

Additional context
This issue is not present when using the Sideband python/pip package. I can run the same radios with two computers (an Ubuntu machine, and an RPi) running the Sideband client without issue. Or even using nomadnet is not a problem either. This issue is somehow specific to the Sideband android app. Similarly, messages sent from the computer to the mobile app will typically succeed. Messages sent from the app always fail.

I have also tried this with the past 3 versions of the app on two different phones.

There is a lack of comments throughout much of the firmware repo. Additional comments throughout would be very useful so we don't have to bother Mark all the time with questions ;)

I will consider doing this myself when I have time considering I (at least like to think) understand most of the firmware now.

Hello can you possibly add the neopixel to the homebrew esp32 version of the firmware?
It would also be nice to have a firmware where we can manually set all aditional pins. In this way most esp32 boards would be supported. Some smaller boards dont have all pins needed.

Really like your project. Currently planing of carpeting my whole town with Rnodes. Building up the nodes.

Can the nodes relay data without them being connected to other hardware?

Hello Mark,

I made some different homemade RNode. Rnode 169MHz basend on ATmega1284p+ RFM95PW-169, a new one 169Mhz based on lolin ESP32 and 868MHz based on T-Beam. Regardles what I set in the reticulum config (0-17dBm) at the 169 rnodes I got 19dBm output and on the TBeam 0dBm output power. I updated rnodeconfig and the rnodes today. I tested also TNC mode with APRSdroid and with examply.py with different powersettings, same result! Did I something wrong? If you want I can send you some of the 169MHz/500mW Lolin RNodes for testing.

Best regards
Tom

The T-Echo device from LILYGO is very similar to the T-Beam devices.

Additional information:

• The T-Echo uses the SX1262 chip.
• Meshtastic supports T-Beam and T-Echo and may be a useful source in case there are subtle differences (hardware devices, development information)

I am happy to fund the purchase of a T-Echo device (around 80 USD for device + shipping fee) in case a developer with suitable expertise is willing to port the RNode firmware to the T-Echo devices.

The thing I've been going on about for so long...

How should we handle this in the firmware?

My first thought is to have a type assigned to every modem object, primary or secondary. Then, when a packet is received, the modem it was received on can be indicated to the host (just like RSSI and SNR). Then, when the host adds packets to be transmitted in reply, it can also specify the modem before writing the packet. This is how I'd imagine interacting with the two working. This also means that both can still generate interrupts and things don't get muddled also.

I also had the idea in my mind of having a connection "upgrade". Imagine 2 boards with a SX1262 and a SX1280 each. When the transmitter sends out a link request, and it's received on the receiver, there could be some kind of config parameter for the interface in reticulum, which specifies that it tries to do this "upgrade" (if it has a second modem with higher data rate of course). So, it responds using the SX1280. If it doesn't hear a reply after a certain timeout, it responds using the SX1262, and carries on as normal. A note should probably be made so it doesn't try the "upgrade" for the same peer again for a certain period. This way, if the link is too poor for the SX1280, or the transmitter doesn't have an SX1280, things still work okay. This should probably be disabled by default and the timeout tuned so as to not create too much disruption. However, it will slow things down. Maybe we could transmit on both at the same time? Of course, you could also send some kind of info in the advertising packet about whether a higher speed link is available, but this would mean adding unnecessary information and I imagine you probably wouldn't like it that way ;)

Please let me know what you think Mark!

Is there a way that I can use this firmware with my own LoRa Board?

I use the following modules.

E32-915T30D 1W Transceiver SX1278 SX1276 915MHz Long Range UART LoRa Module https://ebay.us/L8NcuS

Hi,
Has anyone know how to get the four pin 1306 display to work on the T beam ver 1.1?

It works fine in Meshtastic, looking at the code it is configured for the 1306 multi pin version using pin 13 for the reset.

Many thanks.

Please, add setup for repeater shift (separate TX and RX frequencies).

I purchased a Heltec LoRa 32 board for another project but figured I'd play with RNode after a friend suggested this project. It appears to have an ESP32-S3 chipset on it. Is there support planned for this chipset?

Build does not add the hash for lora32v21_tcxo to release list, or 1.70 github repo includes outdated release.json.

I was trying to build from source and use the upload target in the Makefile. I have an Unsigned RNode gen 2 900 MHz. It was working fine and running RNode v1.57.

1. make firmware-rnode_ng_21
2. Edit makefile to use serial port /dev/cu.wchusbserial54F70179081
3. make upload-rnode_ng_21

The upload works, but the firmware does not start. I unplugged and replugged, the screen just stays black. So then I used rnodeconf -a to restore the firmware, and now the screen says FIRMWARE CORRUPT and the LED is slow blinking red.

Hi Mark,

I have RNode working on the TTGO Lora32 Ver 1 board, as the board is not officially supported the OLED display is not working or the LED's, with the exception of a continuous flashing red one when powered up.

How easy would it to modify the firmware to rectify these minor issues, otherwise everything else works fine, could this be added as feature request please.

I've tried installing from two different distros. Raspberry Pi OS and PopOS. In both cases the install process freezes up at this step.

First line was OK, but 2nd and 3th line always return FALSE, because:
status & SIG_SYNCED == 0x01
status & 0x02 == 0x01
Always return false

and
status & RX_ONGOING == 0x01
status & 0x04 == 0x01
always return false too.

take note, the RX_ONGOING status bit seem to be set when RX is active, always return 1.

Would love to be able to send messages from say, Sideband, to a node and have it bring a GPIO to do things like set high/low, query for status, read data, etc and respond to the sender.

Meshtastic has something like this implemented, so I think it would be possible here as well?

Upgraded Heltec32 to V.1.52 via "sudo chmod 777 /dev/ttyUSB0; rnodeconf /dev/ttyUSB0 --autoinstall". This FW upgrade was successful.
When running Nomadnet or RNSD, I get a number of issue referencing either /dev/ttyUSb0 errors or inability to identify the LoRA radio:

[2022-11-09 12:49:06] [Notice] Serial port /dev/ttyUSB0 is now open
[2022-11-09 12:49:06] [Verbose] Configuring RNode interface...
[2022-11-09 12:49:06] [Verbose] Wating for radio configuration validation for RNodeInterface[RNode LoRa Interface]...
[2022-11-09 12:49:06] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting frequency is 902.3 MHz
[2022-11-09 12:49:06] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting bandwidth is 125.0 KHz
[2022-11-09 12:49:06] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting TX power is 7 dBm
[2022-11-09 12:49:06] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting spreading factor is 8
[2022-11-09 12:49:06] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting coding rate is 5
[2022-11-09 12:49:06] [Verbose] RNodeInterface[RNode LoRa Interface] On-air bitrate is now 3.12 kbps
[2022-11-09 12:49:07] [Notice] RNodeInterface[RNode LoRa Interface] is configured and powered up
[2022-11-09 12:49:07] [Notice] Reconnected serial port for RNodeInterface[RNode LoRa Interface]
[2022-11-09 12:49:07] [Error] A serial port error occurred, the contained exception was: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
[2022-11-09 12:49:07] [Error] The interface RNodeInterface[RNode LoRa Interface] experienced an unrecoverable error and is now offline.
[2022-11-09 12:49:07] [Error] Reticulum will attempt to reconnect the interface periodically.
[2022-11-09 12:49:12] [Verbose] Attempting to reconnect serial port /dev/ttyUSB0 for RNodeInterface[RNode LoRa Interface]...
[2022-11-09 12:49:12] [Notice] Opening serial port /dev/ttyUSB0...
[2022-11-09 12:49:12] [Verbose] Attempting to reconnect serial port /dev/ttyUSB0 for RNodeInterface[RNode LoRa Interface]...
[2022-11-09 12:49:12] [Notice] Opening serial port /dev/ttyUSB0...
[2022-11-09 12:49:14] [Error] A serial port error occurred, the contained exception was: ord() expected a character, but string of length 0 found

These errors are cyclic and repeat for the duration of the session. Similar serial comm errors occur in -N and -T modes.
Please let me know if you need additional logs, etc. I was also unable to downgrade the Heltec FW to see if I could regain use of the radio, I have similar issues with all 3 Heltec radios with V.152, but did not have issues with earlier versions.
Thanks for your time and efforts.

How much would would it entail to make the flashing script work in browser? I'm not a coder but if this isn't a big deal i'm willing to hire someone to do this as a way to help this project grow by making the on ramp much easier..

lmk,

p.s. finally got the new board and setup everything working flawlessly on the ObeliskOne Secure Mobile.

I tried out today the RNode Firmware on a Heltec Wireless Stick. It seem to boot in general but the screen is not correct. The reason seems to be correct, because i installed the only available image for heltec, the one for "Heltec LoRa32 v2" in version 1.64. The Heltec Wireless Stick have a completely different screen size and screen type. I used rnodeconf --autoinstall to install it.

The one i have is: https://heltec.org/project/wireless-stick/

I think the screen issue should be a simple fix for a developer.

Hi, we made rnode Bluetooth ready now

https://github.com/LaneaLucy/RNode_Firmware/tree/mobile_T-Beam

Can you please make reticulum, especially the android version, Bluetooth compatible?
Thx

Is there a way to port this code to ESP-IDF to run RNode on a TTGO T-Beam or like ESP32 based LoRa device?
Cheers
Stephan

MODEM should not be defined in the Makefile compiler flags, it should ideally be done in Config.h as according to the example on line 314 for the RAK4630. This should determine the modem in use, so that they can be tied to the board config (as that's more logical). It's not currently done as I couldn't figure out how to pull in the MODEM value from Config.h in the various different libs of the program, any ideas on how to solve this Mark? Same with the TCXO define too, currently the logic to differentiate that for the SX1262 is commented out.

I have a dead-simple LoRa setup with a SX1276-based HopeRF RFM95W hooked up to /dev/spidev0.0 and thus available from Linux userland. There are Python drivers to run the radio, such as pySX127x and my fork of same, but those kind of need to be built into the application to be useful.

RNode has a good ecosystem, but that software needs to speak the KISS RNode protocol and not straight SPI to the modem. And the RNode firmware here isn't really designed to be buildable as a Linux application.

How feasible would it be to add support to this project for a build mode that turns out a Linux daemon instead of an Arduino firmware, and which e.g. opens a Unix socket for KISS commands and talks to the modem over Linux SPI? With enough #ifdefs anything is possible.

How receptive would you be to a PR that adds that functionality?

Alternately, is there documentation of the samantics (arguments, return values, etc.) of the RNode command set that I could use to build an RNode-compatible soft-TNC daemon like I want on top of the Python driver I've been working with?

How happy would the RNode config tool and so on be if presented with a Unix socket instead of a serial device?

Don't have an arduino toolchain set up and the debian-shipped appears to be about 20 years old, so, here's a patch...

--- a/RNode_Firmware.ino
+++ b/RNode_Firmware.ino
@@ -166,6 +166,7 @@ void receiveCallback(int packet_size) {
     // output directly over to the host
     read_len = 0;
     last_rssi = LoRa.packetRssi();
+    last_snr = LoRa.packetSnr();
     getPacketData(packet_size);
 
     // We first signal the RSSI of the

The current logging implementation basically consists of a couple of Serial.prints on certain conditions.

A robust logging implementation similar to that of Meshtastic should be designed so as to allow for much easier debugging on the host side. Perhaps the RNode should send this over the serial interface following a certain set of bytes, which indicates to RNS this is a log message. Then, the message can be logged and more easily debugged.

Would love support for the Heltec LoRa32 V2.1 boards. From what I can see at initial glance it shouldn't take much to port over. The board is an ESP32-DOWDQ6 MCU with an SX1276 SPI interface LORA chipset.

In regard to the LORA chipset pinout it's very similar to the Lilygo LoRa32 V2.1 board which is already supported except it seems that the reset line is bound to pin 14 instead of pin 23 used by the Lilygo board.

Thoughts? I'd be willing to supply a couple boards for development if needed. Cheapest US-based source I've found for them is Amazon. Although THIS Amazon listing pictures the older version and doesn't have them listed as Heltec brand boards they are shipping the current Heltec LoRa32 v2.1 boards (I've purchased twice so far working on development of another project and had no complaints).

Many OLED screens have burn-in issues, and I'm concerned a 24/7 base station will destroy the OLED screen quite quickly. Is it possible to turn off the screen remotely, or set a configuration bit that will turn off the screen after a certain length of time? I realize it's a complicated consideration as to how it turns off and on, but for an always-on unit, it seems only a matter of time before it burns in.

Hi! 👋

I notice that the fw has by default the battery support disable. I would assume that as in the RGB Led part, this need to be setup at FW and compile. Right? Does this options will always be Compile and upload or would at some point be part of the rnodeconf?

Also.. How is the support for Battery Charge/Discharge for Heltec v2? Any thing that need to be done, besides defining the battery flags and values at the conf.h?

Is possible to understand the use for:

bool battery_installed = false;
**bool battery_indeterminate = false;
bool external_power = false;
bool battery_ready = false;**
float battery_voltage = 0.0;
float battery_percent = 0.0;

Thanks!

Hello I can't seem to get the RNode Configuration Utility to work with the Heltec LoRa32 v2.

When I select it in the list it says "That device type does not exist, exiting now."

The readme states this is a supported device, so I'm guessing this isn't where I go to get this board ready to go?

Hopefully someone can help me figure this out.

This is the wrong place for this, but there is no right place.

Firmware hash lookups return latest value when queried from, for example:
https://unsigned.io/firmware/latest/?v=1.65&variant=rnode_firmware_lora32v21.zip

https://unsigned.io/firmware/?v=1.65&variant=rnode_firmware_lora32v21.zip returns 403.

https://unsigned.io/firmware/1.65 and all its variants return 404

By only providing "latest" it means even with patching the rnodeconf issues old versions of the firmware can only be validated from GitHub hashes.

It's possible it's not respecting the v variable, or it's possible this is an improper endpoint. Please advise.

I'm not sure if this is an issue with the board architecture (nRF52), or the new SX1262 driver, but rnprobe currently doesn't work on this board. A response is never received from the remote destination. I will be investigating this issue further.

I am a novice, so please bear with me.

Of course I am missing "unzip" program, but what is the "unzip" program specifically? The command suggested after the error is only relevant on Linux(sudo apt install unzip).

Is there any way to utilize the config on Windows or does this error suggest the neccesity to use a Linux distribution and "unzip" package?

Thanks

After flashing the latest firmware onto the LilyGo T-Beam, everything appears to work correctly. After power loss, the device doesn't seem to boot up at all. rnodeconf classifies as missing.

The only way I've been able to recover it is to go to https://flasher.meshtastic.org and reset the device. Afterwards, RNode appears with Hardware Failure. Flashing LilyGO LoRa32 v2.1 fixes that issue. The only difference I've noticed between the two firmwares is that the battery icon doesn't work.

Has anyone tried to build for NRF52 devices eg https://www.aliexpress.com/item/1005003652461302.html or would they not be powerful enough. They are very power efficient.

Hi there, I really like this project.
I am interested in SX1262. I was checking LoRa class and you did very hard work there.
How difficult would be to implement another RD module?
Regards!

At present, the return of the packetSnr function is an unsigned integer. This is a bad idea, since some LoRa modems are actually capable of receiving transmissions below the noise floor (meaning the SNR will be negative). These values should be changed to be signed if possible, else this may cause problems when investigating packet SNR in long-range use cases.

There is currently no way to verify the RSSI & SNR values of the SX1262 are being correctly handled by the driver (to my knowledge), I need to check these values seem reasonable (they probably aren't) and fix them if not. #59 must be resolved first to allow me to retrieve the RSSI & SNR values if I'm correct.

As a feature request, I would like to be able to query the battery state over serial, similar to the way you can request the firmware version. Ideally this would take the form of adding a CMD_BATTERY_PERCENT and CMD_BATTERY_STATE which would return a percentage and BATTERY_STATE_CHARGING/DISCHARGING/CHARGED respectively.

I consider this fairly low priority, as a USB tethered node is dependent on the controller's battery state, but it does have a use state for multiple wireless nodes attached to a single hub or when a microcontroller RNS implementation is ready.

Implement promiscuous mode for monitoring any LoRa frames

It would simplify the usability of the device, enabling any device with wifi connection to communicate with the lora network.