@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).

Per comments from @robert-hh & @timh , I used a MAX3232, RS232 to TTL converter chip to resolve the issue.

@jimpower ok, so why do you get no module found when you call urequests.post now when you didn't before. I can't see all your code, just snippets. The vaious sample bits of code are being changed. Oh I see now what the problem is, when you import urequests you are importing as requests hence the module not found error. You will need to change the sample to requests.post Also as an aside why do you execfile('/flash/Wi-Fi/Wi-Fi.py') rather than importing. This seems odd thing to do.

@fsergeys I'm not familiar with Qi chargers, but isn't there a chance the electromagnetic field generated when you transmit data may "trigger" the charger somehow? Since those chargers are designed to be inserted into phones it shouldn't be an issue, but you never know...