search

RAKWireless / WisBlock

Quickstart, tutorials and examples for the RAKwireless WisBlock product line.
https://www.rakwireless.com
MIT License
161 stars 117 forks source link

LoRaP2P example not working #77

Closed possumbytes closed 5 months ago

possumbytes commented 7 months ago

My setup:

Notes:

Issue: no reception of packets by RX unit. The only message rx'd on the Arduino IDE serial terminal of the RX board are the init messages and the OnRxTimeout messages. I've also verified that the OnTxDone() function is running in the TX project via Serial.println() commands.

Right now, I'm just trying to get a TX/RX example working so I can do some range testing. I note that the hardware I'm using doesn't exactly match the recommended HW but it seems like it should be compatible from what I understand. I'm sure I'm missing something though.

I can post the compiler outputs for both projects if needed.

Any thoughts on what might be going on here would be very much appreciated.

Thanks!

beegee-tokyo commented 7 months ago

I just flashed the unchanged example codes on two RAk4631 and they are working fine. image

Question 1, why did you buy the RUI3 variant when you want to use Arduino code?

What could have gone wrong is that the change from RUI3 to Arduino wasn't complete.

Try to double push the reset button, a new drive with RAK4631 should show up. Flash the bootloader + softdevice combination by copying the wiscore_rak4631_board_bootloader-0.4.3_s140_6.1.1.uf2 to this drive. Try the code again.

possumbytes commented 7 months ago

Thank you for your reply!

Answer to question 1: I don't recall why I chose the RUI3 variant. There are a lot of resources for LoRa tech pointing in a lot of different directions - pretty confusing for a beginner in the LoRa world.

My goal is replacing high-power radios in an existing sensor data telemetry application. and I desire BLE on both ends. Additionally, I want BLE on both ends and a module that I could run custom code on for data pre-processing (on the TX side). I wasn't quite sure the best combination but chose what I have based on this more or less.

I tried as you suggested...the drive shows up fine but when I copy the file, the drive immediately unmounts. (question 1) Is this normal? I think it worked - INFO_UF2.txt:

UF2 Bootloader 0.4.3 Model: WisBlock RAK4631 Board Board-ID: WisBlock-RAK4631-Board Date: May 20 2023 Ver: 0.4.3 SoftDevice: S140 6.1.1

Still no luck with TX/RX after doing this though.

Question 2: can you briefly explain or point me to a resource explaining the diff between Arduino and RUI3? Is there a more preferred toolchain for RUI3? Or is this just a matter of the bootloader & softdevice functionality?

Thanks again!

beegee-tokyo commented 7 months ago
(1) Bootloader and Softdevice update is ok now. (2) Drive disappering is normal as well (3) Difference Arduino & RUI3 BSP's RUI3 Arduino
Developed by RAKwireless in house Based on public domain nRF52 BSP maintained by Adafruit
Barebone SDK FreeRTOS based SDK
LoRa/LoRaWAN drivers included Requires third party LoRa/LoRaWAN drivers like SX126x-Arduino or RadioLib
LoRaWAN version 1.0.3 (soon 1.0.4) LoRaWAN version 1.0.2
Supports LoRaWAN Class A, B, C Supports LoRaWAN Class A and C
AT command interface included Required third party library like WisBlock-API-V2
lower power consumption low power consumption

Now regarding the RX/TX problem, did you try to lower the TX power, specially when the device are very close to each other? Or put the modules farther from each other.

possumbytes commented 7 months ago

Very helpful info on the LoRa product space, thank you! I did quite a bit of research before buying but was not aware of this. There are so many LoRa refs on the web, it was pretty confusing.

I've tried both separating them and reduced power, at both 3dBm & 10dBm. No luck in any case.

Side note, I was able to get BLE working on both TX & RX modules. I can connect to both with my phone and get data using a serial-over-bt app (bleuart.write() command). I mention this only to show that I have the HW setup correctly and that both radio modules are working to some extent.

From your reply, I note that the LoRa version and class support varies between the RUI3 & Arduino variants. Is this a HW or FW diff? In other words, perhaps I have simply have incompatible HW.

At this point I can only imagine I either have bad or wrong HW or some issue in my build env setup. I'm attaching the build output for the tx & rx projects...maybe if you get some time you could look through them. Perhaps I have linked to the wrong libs somewhere along the way. I haven't delved into this myself yet. I have lots of time with arm-none-eabi-gcc but am new to the rest of this toolchain and so was hoping to avoid this, but may starting looking into it today. Otherwise, I'm considering ordering new HW and starting again - not sure what else to try.

Thanks again for your help! rx_output.txt tx_output.txt

possumbytes commented 7 months ago

PS: the RX output file I included last still had the #include line in it from my BLE test. Attached output has this removed and so represents a build of the unmodified from the example you have posted. About 100 lines less as a result.

rx_output.txt

beegee-tokyo commented 7 months ago

The differences between Arduino and RUI3 are on the LoRaWAN side and are not relevant for LoRa P2P.

RAK4631 Arduino can communicate to RAK4631 RUI3. Any LoRa transceiver can talk to any other LoRa transceiver as long as you have both setup to exactly the same parameters.

Frequency Bandwidth Spreading Factor Coding Rate Preamble Length Symbol Timeout Fixed payload length IQ inversion

One unsolved weird problem I encountered on RUI3 was that LoRa RX did not work until I did a complete flash erase and re-installed RUI3 fresh.

Did you try to switch the roles of RX and TX between the two modules and check if it changes anything?

possumbytes commented 7 months ago

I did try reversing HW roles, no luck. When you say erase/reinstall RUI3, I assume you mean the bootloader. I have some questions on that.

Q1) The latest release page, the Latest/WisCore_RAK4631_Bootloader page, and the Latest/WisCore_RAK4631_Upgrade page all contain some combo of the hex, uf2, & zip files. Not sure what I'm looking at here as far as differences or which to choose and don't see any readmes or such explaining it.

Q2) I think I may have borked my hw :/ Im pretty annoyed by this. I used pyocd + RAKDAP1 to erase. Per pyocd erase --help ... erase options: -c, --chip Perform a chip erase. -s, --sector Erase the sectors listed as positional arguments. This is the default. --mass Perform a mass erase. On some devices this is different than a chip erase. Based on this, I used both -c & --mass to be "safe". Following this, programming (pyocd flash -t nrf52840 .\wiscore_rak4631_board_bootloader-0.4.3.hex) appears to succeed, but then nothing happens when I plug the module in over USB (no drive, no serial port, double-click reset does nothing). I tried both .hex files found on the 'latest' page mentioned above.

Q3) I'm more than happy to read up on any of the questions I've posted here. However, search as I might, I can find no references that properly explain the questions I'm posting here. My searches seem to end up in out-dated info, vaguely written blog posts, and dead links. And you seem to be the only person on the internet with any real answers haha. Is there any sort of up-to-date doc or whitepaper that really explains this product, toolchain support, etc? I feel like I'm shooting in the dark here - unsurprising I may have bricked my modules:/

Thanks

beegee-tokyo commented 7 months ago

Ok, incomplete tutorial for the bootloader upgrade. You need to flash both bootloader and softdevice files. Can you try to flash both files wiscore_rak4631_board_bootloader-0.4.3.hex and s140_nrf52_6.1.1_softdevice.hex with RAKDAP1. Then it should at least show up as COM port again. Then you should be able to flash the firmware again.

For the RUI3 device, the procedure is similar, just use these files: bootloader_nrf52840_rak4630.hex and s140_nrf52_6.1.0_softdevice.hex

For pyocd, I use the -c option to erase the device.

For the Arduino device, you can try as well to flash the attached file. It is a complete flash memory dump, including bootloader, softdevice and our factory test firmware. You have to get the HEX file inside the ZIP file.

WisBlock_SENS_V2.0.0_2023.11.02.09.57.38+Bootloader.hex.zip

So far I was able to recover any RAK4631 from wrong flashing, unless it was really a hardware defect.

possumbytes commented 7 months ago

Ok, I started from scratch, erased, and flashed wiscore_rak4631_board_bootloader-0.4.3.hex and s140_nrf52_6.1.1_softdevice.hex. This recovered the devices, thanks!!! Commands used and output follow. I'm assuming the "probes not supported" line is irrelevant to my case but let me know if this is an actual issue. 

PS C:\Users\user\Documents\BobsRadioProject\EnvRes> pyocd erase -t nrf52840 -c
0000596 W STLink, CMSIS-DAPv2 and PicoProbe probes are not supported because no libusb library was found. [common]
0000813 I Erasing chip... [eraser]
0001541 I Chip erase complete [eraser]
PS C:\Users\user\Documents\BobsRadioProject\EnvRes> pyocd flash -t nrf52840 .\wiscore_rak4631_board_bootloader-0.4.3.hex
0000580 W STLink, CMSIS-DAPv2 and PicoProbe probes are not supported because no libusb library was found. [common]
0000799 I Loading C:\Users\user\Documents\BobsRadioProject\EnvRes\wiscore_rak4631_board_bootloader-0.4.3.hex [load_cmd]
[==================================================] 100%
0004310 I Erased 37888 bytes (10 sectors), programmed 37888 bytes (10 pages), skipped 0 bytes (0 pages) at 10.73 kB/s [loader]
PS C:\Users\user\Documents\BobsRadioProject\EnvRes> pyocd flash -t nrf52840 .\s140_nrf52_6.1.1_softdevice.hex
0000549 W STLink, CMSIS-DAPv2 and PicoProbe probes are not supported because no libusb library was found. [common]
0000754 I Loading C:\Users\user\Documents\BobsRadioProject\EnvRes\s140_nrf52_6.1.1_softdevice.hex [load_cmd]
[==================================================] 100%
0011646 I Erased 155648 bytes (38 sectors), programmed 155648 bytes (38 pages), skipped 0 bytes (0 pages) at 14.12 kB/s [loader]

I then retested - still no luck :( I also tried swapping the HW rolls at this point, still no luck. I then mounted each and re-copied the wiscore_rak4631_board_bootloader-0.4.3_s140_6.1.1.uf2 file over [not sure if this is still relevant] and retried all - no luck.

I then flashed the WisBlock_SENS_V2.0.0_2023.11.02.09.57.38+Bootloader.hex file on both module. The blue LED flashes and serial reports: 

Wait for input:
Ble Example
----------------------------------------
Advertising is started

Note: when attempting to flash the above, I got an address warning: 

PS C:\Users\user\Documents\BobsRadioProject\EnvRes> pyocd flash -t nrf52840 .\WisBlock_SENS_V2.0.0_2023.11.02.09.57.38+Bootloader.hex
0000587 W STLink, CMSIS-DAPv2 and PicoProbe probes are not supported because no libusb library was found. [common]
0000791 I Loading C:\Users\mpow\Documents\BobsRadioProject\EnvRes\WisBlock_SENS_V2.0.0_2023.11.02.09.57.38+Bootloader.hex [load_cmd]
0001450 W Failed to add data chunk: no memory region defined for address 0x10001400 [file_programmer]
[==================================================] 100%
0058943 I Erased 611328 bytes (150 sectors), programmed 611328 bytes (150 pages), skipped 438272 bytes (107 pages) at 17.83 kB/s [loader]

Plowing ahead, I then re-programmed each module, again trying HW roll swap - no luck in any case.

Any other thoughts?

Thanks!

possumbytes commented 7 months ago

Another thought:

I may be operating under a false assumption. My understanding of the RUI3 variant was that the only user control was via the serial AT interface and that, specifically, I wouldn't be able to implement custom user code on the module. As stated above, this is one of my requirements. I need the modules to act basically as a private, encrypted modem between two serial devices, wired on the TX end and serial-over-BLE on the RX end. As for user code, the TX side needs to preprocess the serial data and I'd like the option to process and react to user input (using available GPIO) on the RX side.

If my assumption is indeed false, and if you think my issues could still be related to the purchase of the RUI3 variant (and not just bad HW), I'd be fine reverting and using a different tool set.

Do you think this is worth trying? Verses the possibility of bad or damaged HW? If so, can you point me at some examples for setup and code [if this exists]?

beegee-tokyo commented 7 months ago

Your problem is kind of strange. I had before a LoRa Mesh network (LoRa P2P) setup for testing and combined Arduino based and RUI3 based devices working fine with each other.

For your questions:

First about 

Wait for input:
Ble Example
----------------------------------------
Advertising is started

The firmware is in factory test mode. Send 'at+user" in all small letters ended with a CR and LF and it will boot into user application.

Second about the pyocd message, despite the warning the files should be flash successfully.

Third about custom firmware You can use the RUI3 API and Arduino IDE (or Visual Studio Code with Arduino extension) and replace the standard firmware with your own firmware. Using the RUI3 API means

possumbytes commented 7 months ago

Thanks for the update. I flashed the RUI3 files you referenced above. The red LED on the module now flashes pretty fast and the module appears to reset about every 2 minutes (windows makes the USB plug/unplug sound). I assume this is normal.

I then started new Arduino IDE sketch per this guide, setup BSP and selected proper board and COM, and attempted to build/load this example (chosen for simplicity). The code builds fine but I get what looks like an error when I program. Other indications that programming failed: after programming the red LED stops blinking but nothing else happens. In the serial monitor, I do not get the serial messages spit out in the Setup() function.

Output following programming attempt: 


Note: Generating a DFU settings page with backup page included.
This is only required for bootloaders from nRF5 SDK 15.1 and newer.
If you want to skip backup page generation, use --no-backup option.
WARNING: Using default offset in order to calculate bootloader settings backup page

Generated Bootloader DFU settings .hex file and stored it in: C:\Users\user\AppData\Local\Temp\arduino\sketches\A21974AFCA8C9C2C7997AC40E7B8B615/settings.hex

Bootloader DFU Settings:
* File:                     C:\Users\user\AppData\Local\Temp\arduino\sketches\A21974AFCA8C9C2C7997AC40E7B8B615/settings.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0x4DC12B7A
* Settings Version:         0x00000001 (1)
* App Version:              0x00000001 (1)
* Bootloader Version:       0x00000003 (3)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x000341AC (213420 bytes)
* Application CRC:          0x1AB1CD91
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x00000000
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

"C:\\Users\\user\\AppData\\Local\\Arduino15\\packages\\rak_rui\\tools\\nrfjprog\\10.15.4/mergehex" -m "C:\\Users\\user\\AppData\\Local\\Temp\\arduino\\sketches\\A21974AFCA8C9C2C7997AC40E7B8B615/settings.hex" "C:\\Users\\user\\AppData\\Local\\Arduino15\\packages\\rak_rui\\hardware\\nrf52\\4.1.0/prebuilt/bootloader_nrf52840_rak4630.hex" -o "C:\\Users\\user\\AppData\\Local\\Temp\\arduino\\sketches\\A21974AFCA8C9C2C7997AC40E7B8B615/bootloader_merge.hex"
Parsing input files.
Merging file "settings.hex" into output.
Merging file "bootloader_nrf52840_rak4630.hex" into output.
Storing merged file.
"C:\\Users\\user\\AppData\\Local\\Arduino15\\packages\\rak_rui\\tools\\nrfjprog\\10.15.4/mergehex" -m "C:\\Users\\user\\AppData\\Local\\Temp\\arduino\\sketches\\A21974AFCA8C9C2C7997AC40E7B8B615/bootloader_merge.hex" "C:\\Users\\user\\AppData\\Local\\Arduino15\\packages\\rak_rui\\hardware\\nrf52\\4.1.0/prebuilt/s140_nrf52_7.2.0_softdevice.hex" "C:\\Users\\user\\AppData\\Local\\Temp\\arduino\\sketches\\A21974AFCA8C9C2C7997AC40E7B8B615/RX_RUI3.ino.hex" -o "C:\\Users\\user\\AppData\\Local\\Temp\\arduino\\sketches\\A21974AFCA8C9C2C7997AC40E7B8B615/RX_RUI3.ino_full.hex"
Parsing input files.
Merging file "bootloader_merge.hex" into output.
Merging file "s140_nrf52_7.2.0_softdevice.hex" into output.
Merging file "RX_RUI3.ino.hex" into output.
Storing merged file.

"C:\\Users\\user\\AppData\\Local\\Arduino15\\packages\\rak_rui\\tools\\arm-none-eabi-gcc\\9-2019q4/bin/arm-none-eabi-size" -A "C:\\Users\\user\\AppData\\Local\\Temp\\arduino\\sketches\\A21974AFCA8C9C2C7997AC40E7B8B615/RX_RUI3.ino.elf"
Sketch uses 212612 bytes (38%) of program storage space. Maximum is 557056 bytes.
Global variables use 60920 bytes (29%) of dynamic memory, leaving 145528 bytes for local variables. Maximum is 206448 bytes.
Performing 1200-bps touch reset on serial port COM4
Waiting for upload port...
No upload port found, using COM4 as fallback
"C:\Users\user\AppData\Local\Arduino15\packages\rak_rui\tools\uploader\0.0.1/uploader.exe" -f "C:\Users\user\AppData\Local\Temp\arduino\sketches\A21974AFCA8C9C2C7997AC40E7B8B615/RX_RUI3.ino.zip" -p COM4 -t "C:\Users\user\AppData\Local\Arduino15\packages\rak_rui\tools\pc-nrfutil\v6.1.3/nrfutil"
2024-04-30 12:00:19,318 Using board at serial port: COM4
2024-04-30 12:00:19,334 Sending Application image.
2024-04-30 12:00:22,836 Serial: Unexpected Executed OP_CODE.
Expected: 0x09 Received: 0x0D
2024-04-30 12:00:22,836 Serial: Set Packet Receipt Notification 0
2024-04-30 12:00:22,845 Sending init packet...
2024-04-30 12:00:22,846 Serial: Selecting Object: type:1
2024-04-30 12:00:22,848 Serial: Object selected:  max_size:512 offset:0 crc:0
2024-04-30 12:00:22,849 Serial: Streaming Data: len:141 offset:0 crc:0x00000000
Traceback (most recent call last):
  File "nordicsemi\__main__.py", line 1545, in <module>
  File "click\core.py", line 1137, in __call__
  File "click\core.py", line 1062, in main
  File "click\core.py", line 1668, in invoke
  File "click\core.py", line 1668, in invoke
  File "click\core.py", line 1404, in invoke
  File "click\core.py", line 763, in invoke
  File "nordicsemi\__main__.py", line 1063, in serial
  File "nordicsemi\__main__.py", line 980, in do_serial
  File "nordicsemi\dfu\dfu.py", line 127, in dfu_send_images
  File "nordicsemi\dfu\dfu.py", line 95, in _dfu_send_image
  File "nordicsemi\dfu\dfu_transport_serial.py", line 256, in send_init_packet
  File "nordicsemi\dfu\dfu_transport_serial.py", line 421, in __execute
  File "nordicsemi\dfu\dfu_transport_serial.py", line 502, in __get_response
pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x07: The array of supported SoftDevices for the update does not contain the FWID of the current SoftDevice.
[15692] Failed to execute script '__main__' due to unhandled exception!
CompletedProcess(args=['C:\\Users\\user\\AppData\\Local\\Arduino15\\packages\\rak_rui\\tools\\pc-nrfutil\\v6.1.3/nrfutil', '-v', '-v', '-v', 'dfu', 'serial', '--package', 'C:\\Users\\user\\AppData\\Local\\Temp\\arduino\\sketches\\A21974AFCA8C9C2C7997AC40E7B8B615/RX_RUI3.ino.zip', '-p', 'COM4', '-b', '115200'], returncode=1)

I tried reconnecting and reset button. I'm not sure what else to try.

I'm happy to pursue any solution that doesn't involve ordering a new set of modules (Arduino variant this time). I hate to think I've wasted the money, and then there's the shipping delay. Seems like every I'm trying is just a new problem though :/:/:/

Any thoughts or ideas? Thank you!

beegee-tokyo commented 7 months ago

The device should not reset every 2 minutes, that is not normal.

While it is up, does it show up as COM port? If yes, connect with a serial terminal app and send AT+BOOT with a trailing CR and LF to force it into boot mode, then try to flash the firmware.

possumbytes commented 5 months ago

Alright bud, thank you so much for your help so far, but I'm still getting nowhere.

After quite a shipping delay, I now have two new board sets (not RUI3 this time) directly from RAKWireless:

I deleted old projects and started anew with your unmodified P2P projects. I followed all setup guides and such. Both boards come up fine. I can control [by adding appropriate code] the baseboard LED and get responsive [debug] serial feedback from both modules, just no TX/RX. Two questions:

1) Are there any HW constraints on freq/channel selection based on the "US915" HW I specified for purchase (these will operate in the US)? For example, I've tried "RF_FREQUENCY 868300000" per original P2P code and "RF_FREQUENCY 902300000" - neither is working.

2) Is there any chance I've somehow linked the incorrect libs, BSP, or some other resource? If you're willing to take a look, I've attached the build outputs with all warnings turned on. I don't see anything serious in the warnings. The LED_BUILTIN pin def resolves the same regardless (value = 35).

Attachments follow. Let me know if you don't see them. Thanks!

P2P TX OUTPUT: tx orig output raw.txt

P2P RX OUTPUT: rx orig output raw.txt

beegee-tokyo commented 5 months ago

Extract the .UF2 file from the attached ZIP file Connect the devices per USB Double push RESET button, they should show up as external drive(s) Copy the .UF2 file to both devices Check the log output of both device WisBlock_P2P_V1.0.0.uf2.zip

The code for this is not simple. It is using my WisBlock-API-V2 library, which does the LoRa handling for your application under the hood and is optimized for low power consumption. It is just a test that your hardware works.

From you compiler logs, you are using the correct libraries. And the compilation is not showing any errors.

beegee-tokyo commented 5 months ago

This is the simplest LoRa P2P code I can think off.

Just running in a loop, every 5 seconds it is sending a packet. Two options for sending

(1) Use CAD (channel activity detection) Recommended, instead of just sending, use CAD (channel activity detection) The packet will be sent if CAD returns no activity in the CAD callback OnCadDone */

(2) Just send without checking for activity Optional, just send data, can lead to collisions and loss of data

LoRa-P2P-Simple-Ard.zip

possumbytes commented 5 months ago

Per WisBlock_P2P_V1.0.0.uf2 test: I did this without removing the existing CURRENT.UF2 file - is this correct? If not, let me know and I'll retest. Results:

Module 1 (TX): on power, red led lights and stays solid; "init_app" message after about 10s; "timer wakeup...LPWAN..." messages come every 10s after that; green led flashes at each. 

[APP] init_app
[APP] Timer wakeup
[APP] LPWAN TX cycle finished ACK
[APP] Timer wakeup
[APP] LPWAN TX cycle finished ACK
...continues in this way

Module 2 (RX): same as above except that red led comes up flashing at 10hz or so; continues to do this until second "Timer wakeup" message, then flashes at around 2hz. Note: red led on module 1 [above] never flashes. 

[APP] init_app
[APP] Timer wakeup
[APP] LPWAN TX cycle finished ACK
[APP] Timer wakeup
[APP] LPWAN TX cycle finished ACK
...continues in this way

I'm not sure what's expected. The only discrepancy I note is the red LED behavior.

Per LoRa-P2P-Siimple-Ard test: I compiled and loaded this this code as-is on each board. In turn, I left one to run on a power supply and monitored the other for serial activity. Results:

Module 1 (TX): on power, red LED on solid; green LED toggles on at each "OnRxDone" message (about every 5s); output: 

=====================================
SX126x LoRa P2P test
=====================================
Starting lora_hardware_init
Starting Radio.Rx
OnRxDone
RssiValue=-36 dBm, SnrValue=13
50 49 4E 47 00 
CAD returned channel free after 12ms
OnTxDone
OnRxDone
RssiValue=-37 dBm, SnrValue=13

Module 2 (RX): same behavior as above; output: 

=====================================
SX126x LoRa P2P test
=====================================
Starting lora_hardware_init
Starting Radio.Rx
OnRxDone
RssiValue=-33 dBm, SnrValue=13
50 49 4E 47 00 
CAD returned channel free after 12ms
OnTxDone
OnRxDone
RssiValue=-33 dBm, SnrValue=13
50 49 4E 47 00 
CAD returned channel free after 11ms
OnTxDone
OnRxDone
RssiValue=-33 dBm, SnrValue=13
50 49 4E 47 00

Looks like something is happening. Thoughts? Thanks!

beegee-tokyo commented 5 months ago

The red LED is connected to the charger chip, it has nothing to do with LoRa functionality.

The compiled code is working, that is a good start. you can study that code to implement LoRa P2P.

possumbytes commented 5 months ago

Alright, thanks. I'd love to know why the other code doesn't work. Pretty frustrating that it works for you but not here, but whatever...I can now move forward. I'll mark this closed.

possumbytes commented 5 months ago

Thank you for all your time.