Thread Tools
Oct 01, 2015, 09:00 PM
Registered User
Thread OP
Quote:
Originally Posted by jt41time
I think a param file export import thing would be helpful. So all the channel and bind codes are the same when updating modules. Setup the first one, export settings. Load the next one, import... Save to module. Just a ease thing.
Good idea, also in the future it won't be necessary to change parameters on both TX and RX.
Sign up now
to remove ads between posts
Oct 01, 2015, 09:07 PM
Registered User
Thread OP
Quote:
Originally Posted by Beemond
I am not sure by what you mean at point three. But, I know for certain that mavlink is present at APM's telemetry port when requested by mission planner via a wired FTDI link. When I use my radio modules, MP sends the connection request packet, but seems as if it is being ignored by the APM. Yet when I first built the modules, and tested with a naze32, cleanflight connected via wireless fine.

My original question; could my symptoms be caused by two wires between the RFM23BP and the Atmel328 being crossed? I would assume that if any wires at all are on the wrong pin, or crossed, I would not be able to get any kind of connection at all.


jt41time, Yes I am running 1.06, as I have never had any issues, and am not keep on running a beta on my expensive machine, that does not yet have a failsafe. Think I'll be safe with beta?
If any two wires are crossed between atmega and rfm module, nothing will work at all.

I would suggest to try the beta, not to fly with it but to check if it connects correctly. I'm confident that you can fly with the beta version, but if it's really an expensive bird it's better to wait let's say one month to have feedback from many other testers.
Oct 01, 2015, 09:11 PM
Registered User
Thread OP
Quote:
Originally Posted by Vex86
It's because, there isn't any simple and complex solution or thay are cosmic expensive. I'm searching for a solution for small local clubs, to have an eye at unexpirienced pilots flying their first routes out of line of instructor sight What I'm doing now is exacly that device but for one plane only. It woud be great to have MAVLink streams form multiple trackers and decode it at custom GS software (I'm gone to create one for that purpose).

It's a little out of topic, so let me know if someday You wake up and think that it might be done I can help as much as I can ( I have some basic electronic and little better programming knowledge ).
Yes it will be done, but as you said it will require a custom GCS to be able to show different planes simultaneously.
Oct 01, 2015, 09:16 PM
Registered User
Thread OP
Quote:
Originally Posted by jt41time
Is there a 5v spot on the modules? I think the 9xr puts out like 6v+ on the outputs. I wan to throw a BT module in side....
No 5V regulator on the modules, but there are 3.3V BT modules, I'm using this one : http://www.ebay.fr/itm/30ft-Wireless.../310540196588?
Oct 01, 2015, 09:25 PM
Registered User
Thread OP
Quote:
Originally Posted by ghostwhiper
where to get a cable/plug that fits in the telemetry port of the apm?
don't want to buy a telemetry set just for the cable.
3DR sells the cable : https://store.3drobotics.com/product...le-for-apm-2-5

I don't remember if there was a change in the number of pins on the telemetry connector of APM 2.5, and more recent ones.

The connector name is Hirose DF13

You can also buy a pack of these :

http://www.ebay.com/itm/8pcs-APM-2-6...3D121523835063
Oct 01, 2015, 09:27 PM
Registered User
Thread OP
Quote:
Originally Posted by jt41time
What sr0 settings do you suggest running with 2.0?
Starting with 2.13, all connections are at 115200 bauds, so APM SERIAL1 must be set to 115.

Notice that UART0 on the board = SERIAL1 parameter.

Always disconnect USB cable from APM when using telemetry, they share the same port.
Oct 01, 2015, 09:29 PM
Just call me Justin.
Quote:
Originally Posted by flipflap
Starting with 2.13, all connections are at 115200 bauds, so APM SERIAL1 must be set to 115.

Notice that UART0 on the board = SERIAL1 parameter.

Always disconnect USB cable from APM when using telemetry, they share the same port.
Im looking for the SR0, SR1 settings...
Oct 01, 2015, 09:38 PM
Registered User
Thread OP
OK sorry, for the telemetry rates I usually set the two first rates (attitude, position) at their maximum (10), and let the other rates by default as they are not so useful during normal flight.

If you're tuning the PID, it can be useful to raise the last rate (sensors).

You can select other rates, the limit is that if in total you try to get more than about 1800 bytes per second it will start to loose some packets.

This can be seen in the 'link stats' in Mission Planner.
Oct 02, 2015, 03:25 AM
Registered User
Quote:
Originally Posted by flipflap
Yes it will be done, but as you said it will require a custom GCS to be able to show different planes simultaneously.
That's great. I'm really looking forward for it. Decoding MAVLink MSGs is not the problem. The problem is to receive it simultaneously at one LRS RX. For now You have to have as much 3DR Radio/URLS RXs as TXs unless one RX can "listen" to multiple TXs. Of Course I'm talking about situation, in which there is no need for two-way communication. All TX would be set to transmit streams automatically.

Quote:
Originally Posted by jt41time
I was thinking the same thing. Check out swarm feature of MP. Don't know what it does, but maybe?????
jt41time, thanks. The problem is not to visualize planes, but to receive MSGs in one RX (as written above).
Oct 02, 2015, 04:01 AM
Registered User
ghostwhiper's Avatar
the tx stil needs to know when to send its information from the rx otherwise you are getting multiple signals over each other.
its no other then packet radio where the stations are talking constantly in a specific order set by the recieving "master" station.
otherwise you will scramble all signals together, everything needs to be coordinated.
Oct 02, 2015, 04:29 AM
Registered User
Thread OP
There are two main approaches :

1) each plane uses a different frequency (or different set of hopping frequencies). In this situation it's possible to have a one-directionnal system, but there will be loss on the transmission of every plane if they're not synchronized somehow, because the RX can't listen to more than one at a time.

2) or each plane uses a different timeslot on the same frequency (or set of)


For 2) it's mandatory to have a perfect synchronization between the planes, so a bidirectionnal system is required.

There will be less modifications to do if we go for the 2) : the planes will all listen to the ground TX, but every packet from ground will contain the target plane number, and only that plane will answer.

There's some logic to add, but this is a simple principle, the bandwidth is divided between the planes. And failsafe, frequency hopping and resynchronization will work without modification.
Oct 02, 2015, 04:53 AM
Registered User
Quote:
Originally Posted by flipflap
There are two main approaches :

1) each plane uses a different frequency (or different set of hopping frequencies). In this situation it's possible to have a one-directionnal system, but there will be loss on the transmission of every plane if they're not synchronized somehow, because the RX can't listen to more than one at a time.

2) or each plane uses a different timeslot on the same frequency (or set of)


For 2) it's mandatory to have a perfect synchronization between the planes, so a bidirectionnal system is required.

There will be less modifications to do if we go for the 2) : the planes will all listen to the ground TX, but every packet from ground will contain the target plane number, and only that plane will answer.

There's some logic to add, but this is a simple principle, the bandwidth is divided between the planes. And failsafe, frequency hopping and resynchronization will work without modification.

2) Option is interesting. Planes would answer only "on demand". It is quite simillar to transponder mounted on a planes. They answers only when "request" from ground radar is received. I like it. I supose, that every plane module (lets name it "RX") will have unique ID set at flashing, and TX will have set number of RXs to answer. Am I right that in this approach there will be bidirectional cummunication to all RX's, like all of them would be connected in parallel? (all of RX woud receive all the data transmitted from the ground, and groundstation will receive data from the RX that it "requested to reply".
Oct 02, 2015, 05:18 AM
Rana
My Futaba 10C with OrangeRX 1W 433MHz with 5V power mod, Firmware: ULRS 2.13b with Telemetry out via Bluetooth.

Bluetooth module: MWC Multiwii Bluetooth parameter debug module / Bluetooth adapter for MWC Flight


No wires re-arrangement required, directly fits with the OrangeRX 1W module.

Just to confirm you that one pair of OrangeRX 1W module with 5V mod had been running days nights since more than two weeks, no failure at all. Today this pair of 5V modified modules have been taken out from testing in healthy condition.

The Bluetooth module I mentioned above works without any issue not BUT DOES NOT WORK IF THIS 5V MOD IS NOT THERE. I mean it does not work with regular OrangeRX 1W modules running on 3.3V.
Last edited by narpat007; Oct 02, 2015 at 12:11 PM.
Oct 02, 2015, 06:19 AM
Registered User
ghostwhiper's Avatar
i finaly have a ftdi programmer.
its switchable 3v3 and 5 volt but im not shure what the other button near the dtr pin does?
havent got any ardiuno experience and dont want to fry anything
its a hdm ch340GH chip
Last edited by ghostwhiper; Oct 02, 2015 at 06:24 AM.
Oct 02, 2015, 07:21 AM
Registered User
Thread OP
Normally on the 1W module there's almost no chance to fry anything (even at 5V on the FTDI), as all components support 5V.

The risk is with the 100mW modules.

I don't know what the other switch is for, maybe to select between DTR and RTS ?


Quick Reply
Message:

Thread Tools