Thread Tools
Jan 31, 2019, 07:35 AM
Registered User
Quote:
Originally Posted by gppsoft
does not light up
Try to flash Arduino bootloader. One of two LEDs is on pin 13 (at least for 100mW RX'es) so "blink" example makes him blink ("blink" already included to bootloader).
Sign up now
to remove ads between posts
Jan 31, 2019, 11:07 AM
Registered User
CHOYADO's Avatar
Quote:
Originally Posted by gppsoft
What am I doing wrong?

I Have:

Fuses: Low=0xF7, High=0xD8, Extended = 0xFD

I am flashing chip firmware.hex But after the firmware does not light up. I am trying to connect via RX and TX on the side of the board, but the configurator does not load the data. Do I have to make any more manipulations with the board? My board is 1W receiver. How to get firmware for receiver? Firmware for RX and TX is same?
I can confirm that the firmware is the same for the TX or RX module. I just Flashed one of these modules last week. After flashing it via USBasp I connected to a FTDI adapter. I only connected TX, RX, and ground and then powered it off of a lipo battery. It connected to CC right away. Do you have another module, say a TX module to confirm that you are able to connect something else to control center. I find control center to be a little finicky at times. Did you do the modifications to the module as described on the website? I did all of the modifications except the DTR pin modification. I figured it was easy enough to flash via USBasp.
Jan 31, 2019, 11:08 AM
Registered User
Thread OP
Quote:
Originally Posted by gppsoft
What am I doing wrong?

I Have:

Fuses: Low=0xF7, High=0xD8, Extended = 0xFD

I am flashing chip firmware.hex But after the firmware does not light up. I am trying to connect via RX and TX on the side of the board, but the configurator does not load the data. Do I have to make any more manipulations with the board? My board is 1W receiver. How to get firmware for receiver? Firmware for RX and TX is same?
Firmware is the same for RX and tx.
Jan 31, 2019, 11:29 AM
Registered User
CHOYADO's Avatar
I have been testing the function of the 1w orange RX receiver that comes in with the bluetooth TX module. A few notes and questions:

1. I tried powering it with a 4s lipo. It seems to work fine at this voltage level.

2. Servo interactions seem fine. I have found that some servos are more susceptible to 433 interference than others but this module does not seem to interact any worse than the previous orangerx tx module that I was using as a receiver.

3. There are three options on the change parameter page for module selection. I believe they are Orangerx, wolfbox, and ULRS mini? (I can't check right now) Which of these option should be used on the 1w rx module?

4. I have discovered one problem with the RX module. I'm not sure what is causing it, I thought that it might relate to a parameter from note 3 above. I have been doing some testing by walking away with my transmitter while RX module that is running in the garage. I walk around the neighborhood, behind concrete walls etc. while watching the RSSI levels. The RSSI levels stay pretty high around 60% at the distances that I am checking. However, I have had it disconnect and the transmitter buzzer goes off. If I walk back to the garage it will not reconnect until I power cycle the RX. Any ideas why this might happen or test procedures I can use to find out what is actually causing the problem?
Jan 31, 2019, 02:19 PM
Registered User
Thread OP
Quote:
Originally Posted by CHOYADO
I have been testing the function of the 1w orange RX receiver that comes in with the bluetooth TX module. A few notes and questions:

1. I tried powering it with a 4s lipo. It seems to work fine at this voltage level.

2. Servo interactions seem fine. I have found that some servos are more susceptible to 433 interference than others but this module does not seem to interact any worse than the previous orangerx tx module that I was using as a receiver.

3. There are three options on the change parameter page for module selection. I believe they are Orangerx, wolfbox, and ULRS mini? (I can't check right now) Which of these option should be used on the 1w rx module?

4. I have discovered one problem with the RX module. I'm not sure what is causing it, I thought that it might relate to a parameter from note 3 above. I have been doing some testing by walking away with my transmitter while RX module that is running in the garage. I walk around the neighborhood, behind concrete walls etc. while watching the RSSI levels. The RSSI levels stay pretty high around 60% at the distances that I am checking. However, I have had it disconnect and the transmitter buzzer goes off. If I walk back to the garage it will not reconnect until I power cycle the RX. Any ideas why this might happen or test procedures I can use to find out what is actually causing the problem?
1. OK
2. Servo jitter is due to RF interference getting caught by the servo cable, some brands are more sensitive to it than others. It's possible to solve it like this : https://www.rcgroups.com/forums/show...7#post39921469
3. 1W RX is OrangeRX.
4. The problem is understood : if something (interference) affects the RFM IO communication, for the moment the firmware doesn't recover gracefully. It shouldn't of course happen but it can for example be provoked by touching an IO pin with a resistor connected to the GND on an ULRS Mini. Check what can cause interferences, use a good power supply and good antenna.
Jan 31, 2019, 02:24 PM
RC fanatic
Flipflap, in your ULRS 2 design, should it be possible to have say: one Tx and Rx, settings perfectly aligned (so same bind code, and same 5 frequencies), link up and running; then next to your model on the bench, another model with ULRS Rx setup and running with same 5 frequencies but different bind code - and have this second model not have any effect on the first model's Tx/Rx link?

I think not - as I tried this on the bench 2 days ago - powered a second Rx which has same freqs configured but different bind code - it had a dummy load on it (instead of antenna), and I simply powered it (no other connections, and my planes link failsafed straight away.

Another piece of trivia - ULRS in the other room left running, whilst in my living room, by sub-woofer (surround sound system) is going nuts! Buzzing loudly at low frequency. Turn off ULRS and the interference gone.
Jan 31, 2019, 02:41 PM
Registered User
Thread OP
I'll check the first point, if it's the case then I'll change the behaviour, it's not supposed to react/transmit if the bind code is incorrect.

For the second point I can't do anything : the RFM does only transmit on its frequency, and the harmonics level respects the datasheet ( see for example http://www.itluxembourg.lu/site/oran...s-measurement/ )

But it's possible for any sound amplifier to catch any RF signal and make a corresponding noise. Hold a smartphone next to an audio amplifier and you'll hear the RF signals (actually their enveloppe, which looks like an AM signal as the RFM transmits and receives alternatively many times per second)

Some audio amplifiers have special circuits to improve rejection of RF signals, see for example https://www.renesas.com/eu/en/www/do...ote/an1299.pdf
Jan 31, 2019, 04:02 PM
Registered User
CHOYADO's Avatar
Quote:
Originally Posted by flipflap
1. OK
2. Servo jitter is due to RF interference getting caught by the servo cable, some brands are more sensitive to it than others. It's possible to solve it like this : https://www.rcgroups.com/forums/show...7#post39921469
3. 1W RX is OrangeRX.
4. The problem is understood : if something (interference) affects the RFM IO communication, for the moment the firmware doesn't recover gracefully. It shouldn't of course happen but it can for example be provoked by touching an IO pin with a resistor connected to the GND on an ULRS Mini. Check what can cause interferences, use a good power supply and good antenna.
I never noticed this with the other RX module I had. It makes me nervous to even attempt flying. When you say "doesn't recover gracefully" do you mean it doesn't recover at all without a power cycle? If I fly out of range it won't reconnect even if the plane executes a RTH maneuver and comes back into range? My experience is that power cycling the TX does nothing, only a a RX power cycle causes it to reconnect.
Jan 31, 2019, 05:10 PM
Registered User
Quote:
Originally Posted by CHOYADO
I never noticed this with the other RX module I had. It makes me nervous to even attempt flying. When you say "doesn't recover gracefully" do you mean it doesn't recover at all without a power cycle? If I fly out of range it won't reconnect even if the plane executes a RTH maneuver and comes back into range? My experience is that power cycling the TX does nothing, only a a RX power cycle causes it to reconnect.
Hi, I agree with CHOYADO, the ULRS system I like it a lot but I'm afraid to fly it because it happened to me exactly that problem, I lost the link, the plane went into RTL but I had it running around without regaining control, finally the plane landed alone without control when it was almost without power (very low lipo), fortunately only the landing gear detached and I could repair it, but I have not flown more waiting for flipflap to publish the solution to this problem.

I have not written before about the problem I had with ULRS because it is a system that I like because it is simple to use it and I do not want to discourage anyone from using it, but the truth is that I am afraid to use it until a corrected version is published. , I do not know if the solution is the same as when the link is lost and the receiver keeps flashing as if it were still linked ...

Greetings from Spain.
Jan 31, 2019, 06:17 PM
Registered User
CHOYADO's Avatar
Quote:
Originally Posted by RICKY24
Hi, I agree with CHOYADO, the ULRS system I like it a lot but I'm afraid to fly it because it happened to me exactly that problem, I lost the link, the plane went into RTL but I had it running around without regaining control, finally the plane landed alone without control when it was almost without power (very low lipo), fortunately only the landing gear detached and I could repair it, but I have not flown more waiting for flipflap to publish the solution to this problem.

I have not written before about the problem I had with ULRS because it is a system that I like because it is simple to use it and I do not want to discourage anyone from using it, but the truth is that I am afraid to use it until a corrected version is published. , I do not know if the solution is the same as when the link is lost and the receiver keeps flashing as if it were still linked ...

Greetings from Spain.
The two times I have experienced this the RX kept flashing as if it were connected. Flip Flap, I'm not sure if this is possible or if the RX is even "aware" of when it has lost connection, but wouldn't the easiest solution be to have the RX reboot when it looses connection? The TX starts beeping when this happens so the system must recognize the connection loss.
Old Jan 31, 2019, 10:47 PM
rc my life
A moderator felt this post violated the following rule: Trolling (Obnoxious behavior). It is temporarily hidden while rc my life edits it.
Jan 31, 2019, 10:52 PM
Registered User
Quote:
Originally Posted by CHOYADO
The two times I have experienced this the RX kept flashing as if it were connected. Flip Flap, I'm not sure if this is possible or if the RX is even "aware" of when it has lost connection, but wouldn't the easiest solution be to have the RX reboot when it looses connection? The TX starts beeping when this happens so the system must recognize the connection loss.
this is fatal bug, I had experienced two time too, RX lost coneection and TX keep beeping, fortuneatly plane on "AUTO" mode, when connection lost two led keep flashing, so FC feel connection still there and excute mission continously, because connection lost already. I can't control it from my TX, my last command of mission is RTL, so plane fly back and land automatically. the distance of lost connection from home is 15KM, from there I can't do anything, just wait. my opinion for using ULRS

1. clean power supply: it seems very senstive if power not stable
2. ULRS mini must be sealed: when you fly high in cloud, moisture high may affect your unit if you don't seal it.
Feb 01, 2019, 04:01 AM
RC fanatic
Quote:
Originally Posted by flipflap
I'll check the first point, if it's the case then I'll change the behaviour, it's not supposed to react/transmit if the bind code is incorrect.
[/url]
Thinking back, the second Bee board, was likely setup as a Tx (with different bind code) rather than a Rx as I suggested previously - thought I'd mention this so you could reproduce the environment accurately. Cheers, Paul
Feb 01, 2019, 04:05 AM
RC fanatic
Quote:
Originally Posted by Greg Covey
Hi Paul,

That reverse label one on the left is weird. If you swap the Vcc and Gnd (because the label is backwards) that could explain no flashing light. It also will kill the WiFi chip.

The images below are how all 4 of mine look with the exception of the WiFi chip surface being silver, not gold. I have only tested two of the four but they were consistent.
Greg, have been testing my original wifi module this week, and have determined that if I set it up as a UDP server (instead of TCP), I maintain a much better connection. I suppose that makes sense given TCP is connection oriented and UDP is datagram. It is still very slow though downloading parameters upon first connect, but useable.

Anyone in here used Tridge's code on a wifi adapter? It acts as a Mavlink relay rather than a pure serial port server, so connection in Mission planner would use the UDP option I guess (instead of UDPCI as I use for the UDP serial connection).
Feb 01, 2019, 05:20 AM
Registered User
Thread OP
I'll post the new firmware this weekend that solves two bugs :

1. Failsafe button doesn't work on ULRS mini boards. (Works fine on ORX boards)

2. RX can have LEDs blinking but no communication until restarted. This happens if the communication between atmega and RFM is interfered, for example touching mosi pin with a resistor to ground. It seems that RF interference (bad antenna, high swr) can cause it too. It can then write random data in rfm registers, and the part of code that should check for this and solve it is disabled by mistake.

Maybe not to be published this weekend, but I've improved the navlink stats tab. It now shows in real time the number of packets of each type received, and also the bandwidth used per packet type. It also computes the frequency of each message, all in real time.

It's useful to try different telemetry rates settings. It's also interesting to see that navlink wastes a lot of bandwidth. Especially by sending data that's not even read by mission planner. Or by sending completely redundant data. And by sending data with an excessive precision. Most values are sent as 4 bytes float, which means about 6 to 9 significant digits. More than required for almost all data.


Quick Reply
Message:

Thread Tools