UART Radio project

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
wilco1967
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: UART Radio project

Post by wilco1967 »

Hi,

Not sure if I'm writing in the correct thread, but here it goes....

I've been flying with the UART radio module (V5 code) and Multiwii EZ-gui for a few weeks now (since I finally got a (used) smartphone), with great succes.
Today, I flew in another location, in a park, in the middle of town, and noticed something strange.

I was flying in GPS pos hold + alt-hold, and sending the copter around the park by giving new waypoints through EZ-gui.
Initially, all was fine, although reception seemed to be not so good, many times lost connection on EZ-gui, and sometimes, it missed a waypoint update.
Then suddenly, after a while, the copter started shaking violently, and almost became uncontrable... managed to get it down undamaged.

As this copter has always been very reliable, and the behaviour looked like totally wrong PID settings, I opened up the PID tab in EZ-GUI, and noted that the pitch/roll rate had mysteriously changed to 2.1. It used to be 0.5. That would explain the behaviour I observed.

So I tried to download the correct settings to the copter using EZ-gui, and it (seemed) to accept it (at least the pitch/roll rate was correct, after I read it back). Tried to fly again, but this time it was very 'jumpy' on the trottle. Landed, and opened the PID settings again, and this time, throttle mid & expo, as well as RC rate & expo were completely off.... (might have been after my initial parameter change... did not check those).

Not sure were these sporadic changes in parameters are coming from.

Could it be the 433 band in the middle of town is much noisier, causing the UART radio to pick up 'garbage', which happens sometimes by accident to be a valid code to change one of the settings ?

Before all this happened, it started to twitch so now and then. Earlier, when I had a bad antenna on 433, I also sometimes noted short glitches in the copter, like it received a wrong RC command for a moment. Seemed like this was happening a few times again today before the PID settings got corrupted.

How much checking is done in the data link in UART code, and/or in MW code ?
Would it be possible, for 'garbage' to make it through, and alter a setting, or is there a checksum, preventing such a thing ?
It might well be the flight controller, which is starting to fail, or EZ-Gui, but neither ever made problems before.

In case it matters, yesterday, I added an extra bluetooth module to my 9X to be able to read Frsky telemetry on android. That works fine. EZ-gui is able to read the data from the Frsky telemetry perfect. Only the RX side is connected, so it cannot sent anything from the phone to the Frsky .
Today, I did not bind to the 9X BT module, only to the UART radio BT module.

FWIW:
I'm using 9X, with Frsky telemetry receiver, and a UART radio module (both together).
Control is normally over 433 (Uart radio), but if it fails, the Frsky receiver will take over (lack of valid serial packets causes MW to go back to PPM serial from the Frsky). This has saved my copter already many times before, particular a few month ago, when the uart radio code still had some issues.

Very strange.....

Any idea ?

Wilco

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: UART Radio project

Post by Alexinparis »

wilco1967 wrote:Hi,

Not sure if I'm writing in the correct thread, but here it goes....

I've been flying with the UART radio module (V5 code) and Multiwii EZ-gui for a few weeks now (since I finally got a (used) smartphone), with great succes.
Today, I flew in another location, in a park, in the middle of town, and noticed something strange.

I was flying in GPS pos hold + alt-hold, and sending the copter around the park by giving new waypoints through EZ-gui.
Initially, all was fine, although reception seemed to be not so good, many times lost connection on EZ-gui, and sometimes, it missed a waypoint update.
Then suddenly, after a while, the copter started shaking violently, and almost became uncontrable... managed to get it down undamaged.

As this copter has always been very reliable, and the behaviour looked like totally wrong PID settings, I opened up the PID tab in EZ-GUI, and noted that the pitch/roll rate had mysteriously changed to 2.1. It used to be 0.5. That would explain the behaviour I observed.

So I tried to download the correct settings to the copter using EZ-gui, and it (seemed) to accept it (at least the pitch/roll rate was correct, after I read it back). Tried to fly again, but this time it was very 'jumpy' on the trottle. Landed, and opened the PID settings again, and this time, throttle mid & expo, as well as RC rate & expo were completely off.... (might have been after my initial parameter change... did not check those).

Not sure were these sporadic changes in parameters are coming from.

Could it be the 433 band in the middle of town is much noisier, causing the UART radio to pick up 'garbage', which happens sometimes by accident to be a valid code to change one of the settings ?

Before all this happened, it started to twitch so now and then. Earlier, when I had a bad antenna on 433, I also sometimes noted short glitches in the copter, like it received a wrong RC command for a moment. Seemed like this was happening a few times again today before the PID settings got corrupted.

How much checking is done in the data link in UART code, and/or in MW code ?
Would it be possible, for 'garbage' to make it through, and alter a setting, or is there a checksum, preventing such a thing ?
It might well be the flight controller, which is starting to fail, or EZ-Gui, but neither ever made problems before.

In case it matters, yesterday, I added an extra bluetooth module to my 9X to be able to read Frsky telemetry on android. That works fine. EZ-gui is able to read the data from the Frsky telemetry perfect. Only the RX side is connected, so it cannot sent anything from the phone to the Frsky .
Today, I did not bind to the 9X BT module, only to the UART radio BT module.

FWIW:
I'm using 9X, with Frsky telemetry receiver, and a UART radio module (both together).
Control is normally over 433 (Uart radio), but if it fails, the Frsky receiver will take over (lack of valid serial packets causes MW to go back to PPM serial from the Frsky). This has saved my copter already many times before, particular a few month ago, when the uart radio code still had some issues.

Very strange.....

Any idea ?

Wilco


Hi,

Every transmission using MSP use a checksum byte to secure data.
But the probability to have both a corrupted message with a good checksum is not null.
I also encounter some glitches sometimes. minor and really flyable, but I still have to check why.

To avoid your major problem, I should maybe prevent the change of any setting while the multi is armed.

wilco1967
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: UART Radio project

Post by wilco1967 »

Hi Alex,

Thanks for the update...

Flew today at my normal location again.... Flew 8 batteries, and not a single issue... All perfect.

Perhaps indeed a good idea, to not accept any adjustments, if armed. However, I heard of some people doing tuning of parameters, while flying.
I also tried that a few times. sometimes, it works, but often, it jolts quite violently as soon as the parameters are written, and It sometimes crashed as a result, so I stopped doing that. Perhaps make adjustment of parameters selectable with a #define, so people can choose.

I personally would prefer to NOT be able to do updates while armed.

Perhaps another thing is to be also able to block updates of the HOME position, while armed. Just to avoid accidently re-setting the home position to a totally wrong location. Should perhaps be solved in EZ-gui, but if the risk exists for 'garbage' signals to do the same, it might be preferred to block this in MW code.

Would a more rigid checksum (2 instead of 1 byte or whatever) be preferred ?

User avatar
NikTheGreek
Posts: 348
Joined: Thu Dec 08, 2011 4:17 pm
Location: Greece
Contact:

Re: UART Radio project

Post by NikTheGreek »

Work bench Success !!! :D
Perfect...now i can see all data sent from vehicle.
Of caurse i have to find out how to change the order of my RC Channels also!!! ;)

Questions..(once again :oops: )

1) There is a way to keep my "traditional" RX connected at the same time ? ..just for contigency reasons in case something goes wrong ?

2) How can i connect RSSI in order to take readings through my MinimOSD ?


Thank you Alex !!!

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: UART Radio project

Post by Alexinparis »

NikTheGreek wrote:1) There is a way to keep my "traditional" RX connected at the same time ? ..just for contigency reasons in case something goes wrong ?

yes :)
just keep the traditional RX connected.
with no signal on the UART line, your traditional RC will regain control after a short timeout (less than 1s)

2) How can i connect RSSI in order to take readings through my MinimOSD ?

Like you used to do on the FC board.
It's then up to mimimOSD to ask RSSI info via UART.

User avatar
city_kid
Posts: 64
Joined: Wed Apr 03, 2013 8:09 pm
Location: Birmingham UK

Re: UART Radio project

Post by city_kid »

Interesting stuff!

So far I've tried the following:

1) Bluetooth(!)
2) NRF24L01+PA+LNA - 2.4GHz 200mW SPI with Arduino serial convertors: Work well!
3) HopeRF HM-TRP - 915MHz 100mW UART transceivers: Bad! Data delayed by long periods!
4) 3DR Robotics - These ARE HopeRF HM-TRP modules, so same problems.
5) Shuncom SZ05-TTL-ADV Serial Wireless Zigbee module - 2.4GHz 250mW Serial Transparent: Perfect! Control and telemetry at 115200 baud no problems!

Let me know if you need any more info....

Cheers!

city_kid

User avatar
NikTheGreek
Posts: 348
Joined: Thu Dec 08, 2011 4:17 pm
Location: Greece
Contact:

Re: UART Radio project

Post by NikTheGreek »

Alexinparis wrote:
NikTheGreek wrote:1) There is a way to keep my "traditional" RX connected at the same time ? ..just for contigency reasons in case something goes wrong ?

yes :)
just keep the traditional RX connected.
with no signal on the UART line, your traditional RC will regain control after a short timeout (less than 1s)


Thank you Alex for your reply..
but..
when my Turnigy 9x Transmitter is connected to OLRS through 3.5mm jack the instaled TX(Turnigy) module is no more active for transmission...
so i guess that somehow the TX module sould be "reconnected" during the OLRS "signal loss" .

An easy solution is to use PPM signal in parallel for both TX modules but i m not sure if can cause any problems.

Any idea ?

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: UART Radio project

Post by Sebbi »

What is the range of those links? Would a lower baud rate increase the range? Why 115200 baud? That's 5000+ 16 bit values per second ... a bit overkill for telemetry ;-)

thebgrian
Posts: 47
Joined: Sun Mar 27, 2011 4:46 am

Re: UART Radio project

Post by thebgrian »

Hi, Alex
You mentioned in another thread that it is possible for you to make a sketch supporting transparent serial with higher baud rates.
With the low price of this modules and the DIY possibilities, I think this will be a great addition to any type of project in need of connectivity between two serial devices.
Is this offer still on the table :)?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: UART Radio project

Post by Alexinparis »

thebgrian wrote:Hi, Alex
You mentioned in another thread that it is possible for you to make a sketch supporting transparent serial with higher baud rates.
With the low price of this modules and the DIY possibilities, I think this will be a great addition to any type of project in need of connectivity between two serial devices.
Is this offer still on the table :)?


Hi,

I'm currently (still :) ) on vacation.
I'll work on it the next week.

An easy solution is to use PPM signal in parallel for both TX modules but i m not sure if can cause any problems.

yes, no risk to duplicate a ppm signal

What is the range of those links? Would a lower baud rate increase the range? Why 115200 baud? That's 5000+ 16 bit values per second ... a bit overkill for telemetry

115200 is the UART interface baud rate (a kind of standard)
but the air link is 57600 baud half duplex, the one which is used by OLRS

thebgrian
Posts: 47
Joined: Sun Mar 27, 2011 4:46 am

Re: UART Radio project

Post by thebgrian »

Thank you for the answer, Alex
Enjoy your vacation :) No rush :)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: UART Radio project

Post by Alexinparis »

thebgrian wrote:Hi, Alex
You mentioned in another thread that it is possible for you to make a sketch supporting transparent serial with higher baud rates.
With the low price of this modules and the DIY possibilities, I think this will be a great addition to any type of project in need of connectivity between two serial devices.
Is this offer still on the table :)?


Hi,

Finally done ;)
because it is a different project from this topic (which is very MSP tied), I open another topic to share the code.

User avatar
NikTheGreek
Posts: 348
Joined: Thu Dec 08, 2011 4:17 pm
Location: Greece
Contact:

Re: UART Radio project

Post by NikTheGreek »

Hi Alex..
Last days EOS introduced new features in his MultiWii communication firmware for 3DR telemetry radios like those depicted below

Image

Do you think that this features can be included to UART project also ?

Thank you...

Post Reply