I will write down my issue a little bit more specific. I would like to communicate with an rs485 device over an wsh-4777 converter. With an usb-rs485 and usb uart converter we manage to debug that the issue probarly that the pycom is unable to pull high enough the rse pin on the wsh-4777 converter. If i hook the sensor to a pc via rs485-usb converter then it's work fine. If i hook the pycom board to the pc via an usb-uart converter, then I see the correct hex array If I listen in between the wsh-4777 and sensor, when it hooked to the pycom, then the sensor gets the value, send the answer back, but the pycom didn't received it. (The rs485 device btw is an RT-ZS-BZ-485 noise sensor) this is the code what I am using: p = Pin('P6', mode=Pin.OUT, pull=Pin.PULL_UP) uart = UART(1, baudrate=9600, pins=('P20','P21'),parity=None, stop=1,bits=8) def f(): p(1) utime.sleep_us(50) uart.write(b'\x01\x03\x00\x00\x00\x01\x84\x0A') utime.sleep_us(50) p(0) utime.sleep_us(50) r = uart.read() print("result is: " + str(r))

@tttadam I think I find the issue. If I shut the pycom down by pluging it out (like the 99,9% of the cases) the sensor wont work. But if I reboot it after I pluged-in then it does work. So my "solution"/workaround is that I check in the boot.py if the checksum is false, if it is, then I do a machine.reset() . Any more elegant solution is welcomed :D

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.