@robert-hh I see, that what I thought. then I will reuse UART1. Thanks :)

@btaillandier The tarball is at https://github.com/robert-hh/Shared-Stuff.git. It's name is: LoPy4-1.20.2.rc11_invert.tar.gz You call the inversion with e.g. from machine import UART uart=UART(1, 1200, invert=UART.INV_RX) there is also UART.INV_TX, UART.INV_CTS and UART.INV_RTS, to be or'ed if required.

@robert-hh I messed up the indexing. Thanks. :)

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

@soopieng said in UART Pins for Pytrack with WiPy3: @Erick-Falcon Hi, I am looking for similar solution as well. May I know what do you mean on making a shield on your solution? I am planning to use FiPy on Pytrack, and i need I2C and UART features from FiPy as well. There is a external IO header on Pytrack board, with some GPIO pins and power signal available. Can we configure one pair of the GPIO as UART for my purpose? or the external IO header is used for other application? hi, I new using these devices. I´ve been work with this around three months. when I said "make a shied" I mean make a pcb what allow you to use fipy, pytrack and sensors, without need to solder extra pins on pytrack. I am testing to see how viable and efficient this solution is.

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