Hi @robert-hh , Both Lopy and Fipy have firmware release='1.18.2.r1'

@misterlisty Pycom bluetooth stack is currently BLE (Bluetooth Low Energy) . And, in BLE there is no SPP equivalent (Simple Port Protocol) as in Standard Bluetooth stack. The BLE normalization is as is, only nordic semi (a ble chip manufacturer) provide a non-standard SPP-like library for it's chip. BUT you can exchange data in BLE, you just have to do it by your self with specific software you write, take a look at how service/characteristics work in ble.

@robert-hh thanks. ill try and sort out some VM's and give that ago.

@testos Yes, you need to connect to the external IO header below the fipy. And you have to specify these Pins, when you open the UART, most likely UART1. On a Fipy, two of the three UARTs are already used by the firmware UART0 and maybe UART2. You have to try.

@robert-hh I managed to get it to work! Thanks for the help! I tried some code i found on the forum so i think it had something to do with my code in the end. I'll try to update this thread with the working code once i finished working on it

@andrejpekarcik UART0 is used for the REPL over USB. The regular speed is 115200. SO if you want to use that, you have to deinit REPL on UART, using uos.dupterm(None), and use Telnet for the REPL.

@robert-hh Thank you, much appreciated.

Big Thanks for the hint! I compiled the firmware with a buffer_len of 4096 instead of 512 and it seems to be working now. At least it says it reads the correct number of bytes. I still have to verify the data ;)

@eric73 This seems to have solved my problem! Thanks!

@robert-hh Hooray! I've got it! Signal wire was broken between pin and GPS. Thanks.

@robert-hh So a remote raw lora receiver with a lot of nodes sending it is just inevitable that collisions happen? My current "solution" is to send and wait for it to send back an acknowledge, if not just wait a random period of time.

@tschili Imho, if you trigger the wake-up just when the transmission starts, you'll have the issue that the GPY needs to little bit of time to wake-up and initialise, and you will most certainly lose and data received during that time. So you would need the SIM800L to wait until the GPY is ready to receive before it start sending the data, and some other way to wake up the GPY.

@jmpratt I cannot believe that you have the same code on both WiPy's. Please reload the code to both devices, reset them and try.

@hopkapi If you connect G24 aka P3 -> 7 G11 aka P4 -> 6 GND -> 8 GND Vin -> 2 (5V) and run the LoPy from USB. then the electrical conditions shoul be OK, and the device shoudl be accessible via UART 1. SOmetimes the definition of Tx and Rx are reversed, so you may swap P3 and P4. That should not cause any harm to the devices. The UART setting according to the data sheet is baud rate: 9600, databits: 8, stopbits: 1, parity: no Some test code would be like: from machine import UART uart = UART(1, 9600) # init with given baudrate uart.init(9600, bits=8, parity=None, stop=1) # init with given parameters while True: data = uart.readall() if data is not None: print(data)

@livius Thank you so much!!! That works for me! Not sure how long it would have taken me to properly use brackets [ ].

@crumble That's interesting, especially since the code for readall still exists. It's just the QSTR definition for that API that disappeared. Reactivating it was not that much of work (just 3 definitions added in 3 files, mods/machuart.c, py/uart.c, py/uart.h). However, uart.read() does the same thing. So at least readall could be kept as an alias to read (1 definition in 1 file to be added, mods/machuart.c).