search

markqvist / RNode_Firmware

RNode is an open, free and flexible digital radio interface with many uses
https://unsigned.io/rnode
GNU General Public License v3.0
145 stars 52 forks source link

Add heltec lora32 v3 #73

Closed cobraPA closed 2 months ago

cobraPA commented 4 months ago

Proposed initial work to add the Heltec Lora32 V3 board for RNode support. Serial only, as this device seems not to support classic Bluetooth and BLE is not fleshed out yet for main repo Sideband use. Comments welcome. I can flash and start this on a sample Lora32 V3, but have not signed locally so it fails full setup with rnodeconf.

cobraPA commented 4 months ago

Cleaned up a couple remaining debug changes with another push.

cobraPA commented 4 months ago

These commits allow me to receive in Loramon from another RNode connected to SidebandOS... I did have to override some startup checks still related to eprom and provisioning. We may also want to make some changes with HAS_BLUETOOTH and HAS_BLE. If you set HAS_BLUETOOTH false then ESP32 will fail in general, due to some coding issues, it seems. With this being a ESP32-S3, I believe it does not really have Classic Bluetooth, so some rearrangement is probably needed.

markqvist commented 4 months ago

Thanks @cobraPA, looking good. Yes, you're right, some rearrangement is needed regarding BLE and Bluetooth.

cobraPA commented 4 months ago

What do you think about BLE and iOS support? Should pairing be enabled by default or would you want it to still require setup with rnodeconf the first time (for BLE enable?) I'm thinking through options to put the iOS BLE in to the main stream firmware and interested in your thoughts. It looks like the BLE added for the sx126x support uses something they call 'the proprietary BLE serial interface from Nordic'. I opted to just use a simple serial buffer and a custom BLE service for the iOS setup for now. Do you have any thoughts going forward if/when you want to use BLE on the Android/Mac/Windows side?

markqvist commented 3 months ago

I initially chose to disable Bluetooth by default, so that devices would not emit any trackable identifiers unless users actively turn it on themselves. Ideally, I'd like it to stay that way, since I really don't like the idea of creating devices that potentially become a tracking vector as soon as they are turned on.

I do realize that it's inconvenient for many users to use the command line utilities, though. Maybe this can be alleviated overall, by having better visibility of the fact that Bluetooth can be enabled via a USB cable from within Sideband (Hardware -> RNode), and adding Bluetooth control to the web-based flashing utility?

cobraPA commented 3 months ago

Yes, agree on the initial trackability risk. I don't have serial working yet for the iPhone version, so turning bluetooth off/on can't currently be done that way. Maybe this isn't ready to go to your version yet (until another platform starts to target BLE maybe? Or I get some serial support working.) Of course, then I was thinking that we are talking about enabling bluetooth for the Lora radio, so those are going to be trackable once powered up anyway? I guess a trade off, Lora can be more burst oriented so theoretically harder to track... although BLE should be lower power and only trackable at close range.

markqvist commented 3 months ago

It's mostly that I don't want it happening without the users actively choosing to enable it. Also, since RNode doesn't transmit any MAC addresses, device identifier or anything similar over LoRa, it makes it much harder to track as well. If you run Reticulum over it with IFAC enabled, there's nothing to track on, apart from a seemingly random signal. But I digress.

Either way, there needs to be a way to enable it easily, of course. I hadn't thought of the obvious situation, that serial doesn't work on iOS! So I guess the best bet is simply to make it easy to enable via both the web flasher and rnodeconf.

And if you want to provide a custom version where BLE is enabled by default, I think that's perfectly fine. I just want to keep it consistent with the already established behaviour here in the main repo.

IceStuff commented 3 months ago

What about if you setup the firmware to read an input pin on boot? Pick a pin next to VCC or GND so it is easy for the user to just short out the 2 pins. By default (no short) then BLE is disabled. If shorted, BLE is enabled. Would that be acceptable for the main stream?

I have recently just found this project (and your other Nomad project) and am looking to start contributing. I have the Haltec V3 boards.

IceStuff commented 3 months ago

@cobraPA could I make a recommendation to rename the board definition from BOARD_HELTEC_LORA32_V3 to BOARD_HELTEC32_V3 to keep the naming profile matching the other versions of this board?

cobraPA commented 3 months ago

Probably we could just add an option to rnodeconf for BLE vs. classic bluetooth enable. I agree with Mark's 'don't power up the radios without notice' policy, and because the initial setup has to flash firmware anyway, there is always access to use rnodeconf (or the new web flasher) at that point. I don't think we would need to have an input tie pin then (but certainly is also an option.) I noticed the difference in HELTEC defines kind of late in the patch submission... The only reason I started with the LORA32_V3 naming was that was what heltec uses for this board in their descriptions. They also seem to have a lot of flavors of the lora boards, so I was trying to get as descriptive as possible. But I can go either way.

cobraPA commented 3 months ago

I pushed updates as discussed and also pushed a Reticulum branch with matching rnodeconf changes.

markqvist commented 2 months ago

Sorry for being a bit slow here, but have had a lot to do. I will test and merge it as soon as I have time.

cobraPA commented 2 months ago

No problem, last version wasn't really all there yet, but this one should be pretty clean... the only thing that I'd like an easier way to switch is serial port in the Makefile... So you will find that my new targets use COM3 / COM4 as I have been testing on a Windows machine, but I see you have linux ports by default. Maybe there is as way we can make that more configurable? I haven't thought about it much yet...

markqvist commented 2 months ago

Yeah, we should definitely have an option to set the serial port on the command line, either via an environment variable, or just as an argument to make.

markqvist commented 2 months ago

Ok, it's all merged and tested out successfully. Thanks so much for the work on this!

I've made a few minor corrections, and added the rest of the support to rnodeconf as well. You can already try out the autoinstaller if you pull the latest Reticulum master from the repo (I added a pre-release H32 V3 build to the exisiting firmware release). It should install on V3 Heltecs with the autoinstaller just fine now :)

ThomasFreedman commented 2 months ago

That's great news. I have 2 of these Heltec V3 boards and will see if I can get the RNode firmware installed as soon Erethon's web installer is updated to do that, unless someone here suggests a guide I could follow as an alternative.

Great work on this guys!

liamcottle commented 2 months ago

Flashed to Heltec v3.1 board via MacBook Pro:

# clone repo
git clone https://github.com/markqvist/RNode_Firmware
cd RNode_Firmware

# checkout this pr
gh pr checkout 73

# make firmware
make clean
make firmware-heltec32_v3

# flash via custom port
arduino-cli upload -p /dev/tty.usbserial-0001 --fqbn esp32:esp32:heltec_wifi_lora_32_V3

After Flashing

IMG_6493

After pressing RST button

image

liamcottle commented 2 months ago

Got this working by pulling latest master branch from Reticulum repo, and following on screen instructions :)

git clone https://github.com/markqvist/Reticulum
cd Reticulum/RNS/Utilities
python rnodeconf.py -a

Looks like it needed to flash a few extra things.

IMG_E8782A473A15-1

ThomasFreedman commented 2 months ago

Thanks @liamcottle that simple procedure worked flawlessly. It does require installation of the Silicon Labs CP210x UART Bridge, which I did on one VM to install Meshtastic on the Heltecs, which has now been replaced with RNode firmware.

Next to play with Sideband and see about accessing the RNode Bootstrap Console via WiFi.

ThomasFreedman commented 2 months ago

Sideband started when I connected the programmed Heltec, but not sure of next steps.

Do I connect via serial port or WiFi? I'm using an old Android phone without a SIM card, connected to the Heltec with a USB cable that also powers it. I disabled Bluetooth under Hardware/RNode. Based on what I read here classic Bluetooth is problematic and BLE still has a few kinks.

I may need to do some manual config in Sideband / Reticulum so I need to investigate that.

ThomasFreedman commented 2 months ago

Can't activate the RNode Bootstrap Console (press the reset button twice with a one second interval 1 second between presses, press twice within 1 second, press & hold for 1 second then repeat?) Tried lots of viations but phone doesn't connect to it via WiFi with a web browser.

cobraPA commented 2 months ago

@ThomasFreedman , the console is currently disabled, but I suspect it may work if we enable it. I made a comment that BLE and Wifi might not run at the same time, based on some online discussion I read for the S3 chip. But further reading suggests that was not the case. Also, when console mode is enabled we don't use the BLE anyway, so we should test and see if it works.

cobraPA commented 2 months ago

I did a quick test and forget the firmware uses the bluetooth to make device name for WiFi. Without the BLE or Bluetooth currently enabled we need to work that out first.

faragher commented 2 months ago

Suggestion: If device name is arbitrary and simply needs to be persistent, device serial number or WiFi MAC address could be used. Since the WiFi address only matters if there's a WiFi adapter, pulling the MAC might be the most resilient way.

Not to say it should be changed over, but as a failover without Bluetooth, it may be a good solution.

TheTimC commented 2 months ago

Got this working by pulling latest master branch from Reticulum repo, and following on screen instructions :)

git clone https://github.com/markqvist/Reticulum
cd Reticulum/RNS/Utilities
python rnodeconf.py -a

Looks like it needed to flash a few extra things.

IMG_E8782A473A15-1

Awesome, this let me install rnode on my v3, many thanks. Now I just need to have bluetooth working. I'll keep an eye on this thread. Thanks all.

markqvist commented 2 months ago

I made a few structural changes yesterday as well to better support all ESP32-S3 based boards. Those commits also lay down the very basics for BLE support on this platform and enables proper boot and device name generation from a hash of the BLE mac and EEPROM signatures (we don't want a direct one-to-one relationship between the MAC and the device name, for tracking purposes).