|
|
|
|
|
|
|
|
|
Thread OP
|
I just may do that. but I already have the inverter on my test board and code for SBUS ready to go, so when the FC arrives so I can test, that is what I will do first just to make sure it all works. I may just put them both in.
|
|
|
|
|
Thread OP
|
So then there is a different receiver on the ground for the telemetry packets? Meaning that the multi module would ignore these "even" packets and a separate receiver on the ground would receive the passed through telemetry packets? Is that the jist of this?
|
|
|
|
|
|
Bump!!!!
The problem with the nRF24L01+ is that do not have a signal strength indicator register just only a signal carry detect bit. Without a signal strength indicator register you could never know how far is the TX from the RX. Monitoring the Signal Strength indicator every time the TX and RX send a package can be very beneficial before so the System can recover before loosing a plane. Before the Chicken(hen) was the Egg or the other way around. https://www.rcgroups.com/forums/show...oup_Tx_Rx_0001 |
|
|
|
||
|
Quote:
The telemetry packets would be sent to the serial port where it can be connected to the ground station and aircraft. The problem is then the 328 doesn't have enough serial ports for sbus and telemetry so you would have to use another chip or use soft serial for telemetry, 19200 would be fast enough. |
|
|
Last edited by geofrancis; Jun 20, 2017 at 09:58 PM.
|
|
|
||
Thread OP
|
Quote:
As this looks like a complete overhaul to do something like this, so I am not going to work on it at this time, but who knows what the future may bring. It is interesting stuff, just not where I am at right now. |
|
|
||
|
||
|
Quote:
Ulrs is more similar to to your system. Telemetry and RC in the same packet. |
|
|
||
|
|
Thread OP
|
The problem with these LSR projects you keep referring me to is that there is no introductory documentation. I have not done anything in that space I really have no concept of what they are doing, so I need an introduction for context. All the documentation I have found jumps in at a detailed level, that for me is out of context. I am just not ready at this point to invest many hours pouring through details just to get enough basic understanding to evaluate if I can do the same thing. It is really rather frustrating. One web page with right content could very well hook someone like me, but instead it is just frustrating.
|
|
|
|
|
Thread OP
|
Ok, I think I finally found enough on the LRS stuff to get the the idea of what they are doing. It is really interesting stuff that I may pursue sometime, but here is my take on it as it relates to this specific receiver project:
I think the reason that what geofransis would like to see in 2.4 Ghz doesn't exist is because 2.4 is pretty short range. I think LRS just isn't very compelling at the ranges we can reliable get from the NRF24L01. It is true that some 2.4 systems get better range, but from what I can glean from the info I found, I think that they are going it by reducing the data rate to make longer ranges more reliable. For example FRSKY gets better range than the NRF24L01, but from what I read, they run a data rate of 31 kbps. The slowest data rate available on the NRF24L01+ is 250 kbps, so it makes sense that they will get better range, but they do so at the expense of packet latency. Looks like FRsky has a packet rate of 9 ms for 8 channels and 18 ms for 16 channels. With this protocol on the NRF24l01+, we get a 3 ms packet rate without telemetry for up to 16 channels, and a worst case of 4ms packet rate with telemetry. With telemetry the packet rate is 3 ms for 6 channels and gradually increases to 4 ms for 16 channels. This receiver protocol is more suited to direct control instead of LRS. It has low latency for a responsive model. Even with the added latency of talking to the multi-module (7 ms), most setups will have 10 ms average transmission latency or a worst case 11 ms. Even using the module this is very close to built in latency using FRSKY, and much better than FRSKY when using over 8 channels. But, assuming power output is approximately the same, FRSKY will get better range - it is simply the nature of the different chips being used. All this being said, I think some sort of pass-through return telemetry is likely feasible. Mavlink has some long messages, which would cause issues on the NRF24L01 because the max packet length is only 32. Having to piece together multiple packets would likely be unreliable, but adding a pass through for shorter telemetry packets I think is a viable future feature. I'm not sure right now if the Multi-protocol module supports pass-through, so there may need to be work done there first. |
|
|
|
||
|
Quote:
it gets around 300 bytes/s with 16ch rc and the radio running at 19200 baud, at 115200 ULRS gets around 1.5kb/s, if like you say the minimum speed you can run at is 250000 baud then you should be able to get some very impressive speeds. if you can get 1km it will be more than enough for most machines, in most of the world you cant legally fly more than 500m anyway, so 1km would give plenty of safety net. openlrsng has a multimodule profile in opentx, i think they use softserial for the taranis interface that left the hardware uart free for telemetry. |
|
|
Last edited by geofrancis; Jun 23, 2017 at 08:54 PM.
|
|
|
|
Thread OP
|
the NRF24L01+ in theory does 1 kilometer, but I have yet to see that distance. I use the cheap Chinese modules, so I would guess a high quality Nordic module does better - if you can find them for a reasonable price.
I ground tested a non-diversity receiver at 0ver 400 meters. In the air you may see 500. Also, I don't have a good explanation for it, but telemetry is lost well before the control signal fail-safes. |
|
|
|
|
Thread OP
|
Here is a picture of a diversity receiver. The board it is on was designed for only one module and is an earlier revision that the one on GitHub, but it shows how 2 NRFs can be stacked. This shows 2 NRF24L01+ PA/LNA modules is a stacked configuration. The SMA connectors were removed and coax soldered directly onto each module. There is 2 layers of heat shrink around each module with copper tape for shielding in between (copper tape is connected to ground). The pin headers on the modules also needed to be removed and all extra solder wicked away.
The CE pin on each module is connected to 3.3V by bridging the second and third little half-hole edge pads with a small bit of wire (I used the cut off lead from a resistor). The CSN pin on for the top module is connected down to the main board by threading a piece of insulated wire (I use a strand of cat 5 Ethernet wire) through the holes for the CE pin header. The diodes on the IRQ pins are soldered into each modules IRQ pin header holes (cathode side), then joined together (on anode side) and wrapped around the bottom module to get to the main board (protected with heat shrink). Please refer to the hardware folder on GitHub for the schematic. A board design specific for diversity receivers is still pending. I still have several of these older boards that I need to use |
|
|
Thread Tools | |
Similar Threads | |||||
Category | Thread | Thread Starter | Forum | Replies | Last Post |
New Product | CrystalVideo - HD Digital Video for FPS (Open Source Project) | gyrex | FPV Equipment | 130 | Feb 03, 2021 07:20 AM |
Discussion | Open Source Ornithopter Project | CosmicDog | Ornithopters | 17 | Jan 23, 2019 02:22 PM |
Discussion | OPENVTX - Open Source VTX project? | downloader9 | FPV Equipment | 0 | May 23, 2017 07:15 AM |
Help! | 3D printable open-source RC Truggy - RC minds needed to finish project | remondo | Off-Road Vehicles | 21 | Sep 16, 2014 12:35 AM |