Thread Tools
Jun 27, 2019, 09:49 PM
Registered User
Flipflap,

I ordered some mini ULRS Starfish board but I have not received it yet, it's been four months and still nothing. I will redo the order but I will have to wait.

In the meantime I've thought of a way to deploy 1K Ohms resistors to protect the RF module in my HobbyLink Bluetooth 1W receiver with Bluetooth.

The idea is to unsolder the RF module and place resistors in the SMD 0805 format, vertically. 0 Ohms resistors where the connection is direct and 1K Ohms where it is needed.

The RF module will be spaced from the board by the length of the resistors, which is 2.6mm.

Do you think this idea is too bad?

If I think I'm going to succeed, see if the pins of the RF module are correct that 1K Ohms resistors will be added: SDO, SDI, SCK and NSEL.

Do you have any other recommendations?

I will also make the modification suggested by Narpat007, "Narpat mod to use it with ULRS", for connection of PPM and RSSI.

Thanks.
Sign up now
to remove ads between posts
Jun 28, 2019, 12:09 AM
Registered User
Thread OP
Where did you order the PCBs ? Four month looks like it's lost somewhere.

For the Orange module with bluetooth, the main issue is that it's powered at 5V, and that the RFM can only accept 3.3V on its IO pins.

One of the options would be to add resistors on the IO pins, and this is how it's done on the ULRS Mini modules. But don't do that on the Orange module.

The other option is to change the voltage to 3.3V, and for that Orange module it's the simplest option. Just do the two mandatory mods described here : http://www.itluxembourg.lu/site/oran...roller_voltage


My recommandation is to keep things simple, with minimum modifications. In the meanwhile order the normal OrangeRX modules without bluetooth, or Wolfbox modules, they will work out of the box without any mod.

At least when you start, go with the simplest possible system, and then try the mods as you get more experience.
Jun 28, 2019, 12:00 PM
Registered User
Quote:
Originally Posted by flipflap
Where did you order the PCBs ? Four month looks like it's lost somewhere.

For the Orange module with bluetooth, the main issue is that it's powered at 5V, and that the RFM can only accept 3.3V on its IO pins.

One of the options would be to add resistors on the IO pins, and this is how it's done on the ULRS Mini modules. But don't do that on the Orange module.

The other option is to change the voltage to 3.3V, and for that Orange module it's the simplest option. Just do the two mandatory mods described here : http://www.itluxembourg.lu/site/oran...roller_voltage


My recommandation is to keep things simple, with minimum modifications. In the meanwhile order the normal OrangeRX modules without bluetooth, or Wolfbox modules, they will work out of the box without any mod.

At least when you start, go with the simplest possible system, and then try the mods as you get more experience.
flipflap, thank you very much for the recommendations, I will continue and order new mini ULRS and in the meantime use a 100mw RX Orange module.
Jun 29, 2019, 08:04 AM
Registered User
Thread OP
Working on the Raspberry pi based ULRS 3.X, it can now communicate with an ULRS 2.X (RC and telemetry).

But it's not really a microcontroller so it can't read the PPM frames correctly. The microcontrollers have precise interrupts and timers and can easily measure a PPM signal with submicrosecond precision. A raspberry pi can do a lot other stuff, but is built around a Linux OS and can't make precise signal measurements.

So I'm rather considering support for the serial RC protocols.

First looked at SBUS, but the signal is inverted so an external inverter would be required (a transistor and 1 or 2 resistors), which I'd prefer to avoid. I've also checked in the OpenTX code, it should be relatively easy to make a version that outputs non inverted SBUS.

So I'm now looking at the CRSF protocol, which is even faster than SBUS. It works at 400 kbps vs 100 kbps and sends a frame every 4 ms. The advantage is that it's not inverted so I can read it directly from the Raspberry without inverter.

Just wondering if someone has some clue about the details of the CRSF protocol ? It shouldn't be too difficult to reverse engineer as I see which bytes are changing when moving sticks, but if there's some documentation already existing I'm interested. Google didn't provide a lot of help in this specific case.

So I start to see the limitations of the Raspberry, for example it has only one UART, and can't make correct PPM signal measurements. For the first point it's not really an issue as on the TX part it can be connected to a computer or smartphone in a number of ways : Ethernet, Wifi, Bluetooth, USB.

But apart from these two points, the raspberry continues to provide many advantages and is especially fast to program and debug.
Jun 30, 2019, 08:09 PM
Registered User
Quote:
Originally Posted by flipflap
Working on the Raspberry pi based ULRS 3.X, it can now communicate with an ULRS 2.X (RC and telemetry).

But it's not really a microcontroller so it can't read the PPM frames correctly. The microcontrollers have precise interrupts and timers and can easily measure a PPM signal with submicrosecond precision. A raspberry pi can do a lot other stuff, but is built around a Linux OS and can't make precise signal measurements.

So I'm rather considering support for the serial RC protocols.

First looked at SBUS, but the signal is inverted so an external inverter would be required (a transistor and 1 or 2 resistors), which I'd prefer to avoid. I've also checked in the OpenTX code, it should be relatively easy to make a version that outputs non inverted SBUS.

So I'm now looking at the CRSF protocol, which is even faster than SBUS. It works at 400 kbps vs 100 kbps and sends a frame every 4 ms. The advantage is that it's not inverted so I can read it directly from the Raspberry without inverter.

Just wondering if someone has some clue about the details of the CRSF protocol ? It shouldn't be too difficult to reverse engineer as I see which bytes are changing when moving sticks, but if there's some documentation already existing I'm interested. Google didn't provide a lot of help in this specific case.

So I start to see the limitations of the Raspberry, for example it has only one UART, and can't make correct PPM signal measurements. For the first point it's not really an issue as on the TX part it can be connected to a computer or smartphone in a number of ways : Ethernet, Wifi, Bluetooth, USB.

But apart from these two points, the raspberry continues to provide many advantages and is especially fast to program and debug.
flipflap, I saw the application of this protocol here with descriptive text in the code, I do not know if it is what you are looking for:

https://github.com/cleanflight/clean...main/rx/crsf.c

and the link to the application on the PX4 controller:

https://github.com/PX4/Firmware/blob.../lib/rc/crsf.h
Last edited by helixerox; Jun 30, 2019 at 08:54 PM. Reason: added the link with the application on the PX4 controller
Jun 30, 2019, 08:32 PM
Registered User
Just rember Raspberry Pi is the effect of a corrupted SD card
i found the SanDisk Extreme Pro works the best
i have had many SD card in my Pi
the SanDisk Extreme Pro has not let me down

Quote:
Originally Posted by flipflap
Working on the Raspberry pi based ULRS 3.X, it can now communicate with an ULRS 2.X (RC and telemetry).

But it's not really a microcontroller so it can't read the PPM frames correctly. The microcontrollers have precise interrupts and timers and can easily measure a PPM signal with submicrosecond precision. A raspberry pi can do a lot other stuff, but is built around a Linux OS and can't make precise signal measurements.

So I'm rather considering support for the serial RC protocols.

First looked at SBUS, but the signal is inverted so an external inverter would be required (a transistor and 1 or 2 resistors), which I'd prefer to avoid. I've also checked in the OpenTX code, it should be relatively easy to make a version that outputs non inverted SBUS.

So I'm now looking at the CRSF protocol, which is even faster than SBUS. It works at 400 kbps vs 100 kbps and sends a frame every 4 ms. The advantage is that it's not inverted so I can read it directly from the Raspberry without inverter.

Just wondering if someone has some clue about the details of the CRSF protocol ? It shouldn't be too difficult to reverse engineer as I see which bytes are changing when moving sticks, but if there's some documentation already existing I'm interested. Google didn't provide a lot of help in this specific case.

So I start to see the limitations of the Raspberry, for example it has only one UART, and can't make correct PPM signal measurements. For the first point it's not really an issue as on the TX part it can be connected to a computer or smartphone in a number of ways : Ethernet, Wifi, Bluetooth, USB.

But apart from these two points, the raspberry continues to provide many advantages and is especially fast to program and debug.
Jun 30, 2019, 11:36 PM
Registered User
Thread OP
Thanks for the info, didn't get into this issue for the moment but we'll see.
Jun 30, 2019, 11:41 PM
Registered User
Thread OP
Quote:
Originally Posted by helixerox
flipflap, I saw the application of this protocol here with descriptive text in the code, I do not know if it is what you are looking for:

https://github.com/cleanflight/clean...main/rx/crsf.c

and the link to the application on the PX4 controller:

https://github.com/PX4/Firmware/blob.../lib/rc/crsf.h
Thanks, yes that's useful it describes the structure of the packets. I had found something similar in OpenTX and this protocol is extremely simple and fast if we just read the RC data.
Jul 02, 2019, 10:49 AM
Has anyone successfully built the "butterfly board" from cereal killer? I ordered some from Oshpark a year or so ago when i was just browsing their "shared" section before I even knew about this thread. I now notice, when I am gathering the parts to build them, that it says on the site there are problems with that board. Did anyone ever figure it out? Or am I better to build something like the Bee Board.
Jul 06, 2019, 12:16 PM
Multirotors are models too!
Hey guys, giving this a go again now that I have some free time. Still can't seem to flash the OrangeRx jr module.

Hardware:
OrangeRx 1W jr module, added the DTR pin
Adafruit "FIDI Friend" for flashing firmware

Tried many combinations of power and signal level (VCC 5V or 3.3V, Signal at 5V or 3.3) Fidi friend can be configured many ways, DTR was enabled)

I am trying to flash the module out of the radio. What am I missing?? Does the module need to be in the radio when flashing?

This is a snap shot of the error.
Latest blog entry: Test entry
Jul 06, 2019, 09:54 PM
Registered User
Roberto Finger's Avatar
Quote:
Originally Posted by Rusty105
Hey guys, giving this a go again now that I have some free time. Still can't seem to flash the OrangeRx jr module.

Hardware:
OrangeRx 1W jr module, added the DTR pin
Adafruit "FIDI Friend" for flashing firmware

Tried many combinations of power and signal level (VCC 5V or 3.3V, Signal at 5V or 3.3) Fidi friend can be configured many ways, DTR was enabled)

I am trying to flash the module out of the radio. What am I missing?? Does the module need to be in the radio when flashing?

This is a snap shot of the error.
I also had the same problem! I made the flash using avrdude through the ISP pinning
Jul 08, 2019, 04:18 PM
Registered User
Thread OP
Quote:
Originally Posted by Rusty105
Hey guys, giving this a go again now that I have some free time. Still can't seem to flash the OrangeRx jr module.

Hardware:
OrangeRx 1W jr module, added the DTR pin
Adafruit "FIDI Friend" for flashing firmware

Tried many combinations of power and signal level (VCC 5V or 3.3V, Signal at 5V or 3.3) Fidi friend can be configured many ways, DTR was enabled)

I am trying to flash the module out of the radio. What am I missing?? Does the module need to be in the radio when flashing?

This is a snap shot of the error.

The flashing just calls avdude in the background, so you can test it simply with Arduino IDE and try to flash the "blink" sketch for example. The board has to be powered (not necessarily by the radio) during flashing. Don't power it from the FTDI cable.

I recommend to use genuine FTDI cables for best results, I've encountered some FTDI clones that didn't work correctly for the flashing.

Normally the RTS pin should have the same effect as the DTR pin, i.e. change its level when the programming begins, and that make a reset of the atmega (which launch the bootloader code).
Jul 09, 2019, 10:08 AM
Multirotors are models too!
Quote:
Originally Posted by flipflap
The flashing just calls avdude in the background, so you can test it simply with Arduino IDE and try to flash the "blink" sketch for example. The board has to be powered (not necessarily by the radio) during flashing. Don't power it from the FTDI cable.

I recommend to use genuine FTDI cables for best results, I've encountered some FTDI clones that didn't work correctly for the flashing.

Normally the RTS pin should have the same effect as the DTR pin, i.e. change its level when the programming begins, and that make a reset of the atmega (which launch the bootloader code).
Yep, I tried again, powered the module with a 5V BEC, Used a FIDI adapter, with the VCC pin disconnected, and still not working,. I am going to get another FIDI cable and see if that works. It's odd though. the FIDI adapter (Adafruit FIDI Friend) works flawlessly with my Arduino minis and other devices....
Latest blog entry: Test entry
Jul 17, 2019, 08:17 PM
Rana
It looks like this thread is dying now, no post in last 9 days !
Ben, folks are loosing charm, I think you should seriously re-think of releasing the latest code so that many others can also contribute in the latest code and not the one which was released in ancient times.
Jul 18, 2019, 01:57 AM
Registered User
Thread OP
Hi Narpat,

Yes the goal of making a very stable system and good documentation is to avoid having too much support to provide.

Regarding the sources, ULRS 1.X is open source and ULRS 2.X is closed source.

If there's a specific feature that you'd like let me know and I could include it in ULRS 3.X

ULRS 3.X is raspberry pi zero based and doesn't have the hardware limitations of ULRS 2.X so for example SBUS is supported by default.


Quick Reply
Message:

Thread Tools