This method is superior to FrSky telemetry, which at best, tries to recognize, and encode the messages, then a .lua script in the transmitter is supposed to display a corresponding/equivalent message. That method works only for known messages (depending on firmware), and things can get “lost in translation”.
This device, however, just display text as-is, and thus can display new and future messages as well as composite messages that may contain variables or debugging info.
The device can be user-updated using an inexpensive FTDI cable (same cable as used to update MinimOSD)
Instructions and firmware will be posted on this site.
Low battery and critical battery alarms;
3s Warning 10.8v , Critical 10.2v
4s Warning 14.2v , Critical 13.6v
5s Warning 18.0v , Critical 17.0v
6s Warning 21.5v , Critical 20.4v
Warning inverts/flashes the part of the display that contains battery information, and give relaxed audible warning. The LEDs, if connected, are blinking diagonally (only warning/critical state does that)
Critical battery level does the same, but the audible warning is more intense, and rapid, LEDs are flashing diagonally very fast.
Detected cell count can be seen as number of displayed cell-voltages (which is calculated from initial battery voltage)
most useful information at a glance, by using just heading, and flying so it gets equal to gearing to home – you can fly home even without seeing the model.
Mavlink mode-controlled LED controller.
There is no need for HoTT telemetry to be sent, only read the Mavlink protocol input, for the LED controller to work.
For ArduCopter, there are four outputs for leds/strips (non-amplified, so you will need a transistor if you wish to use them with more than a few LED’s)
The blinking patterns are different for each mode, but follow this system:
Stabilize = solid on
Alt-hold = short off-time on rear leds
Autopilot modes does not have solid front light, indicating that AP is on
Diagonal blinking patterns are used for errors, noGPS fix, low battery, and anything else that may be reported over 3DR radio/mavlink as an critical state.
Warning/Critical blinking ignores LED Switch function.
The outputs are on pin 7(RearLeft),8(RearRight),9(FrontRight),10(FrontLeft) . – they will flash diagonally in case of critical events, and different patterns depending on mode/situation , GPS fix and so on.
LED Switch function: if pin2 gets a PWM betwen 900…1200µs , the LEDS goes dark except if critical condition, or a battery warning – in case of which, the PWM will be ignored, and LEDs will flash anyway.
The device does only read mavlink, (it’s connected to telemetry TX pin) , fed with power from receiver or telemetry port, and so it is unable to influence the operation of the autopilot in any way.
Voltage: GND and +5v goes to Pixhawk/APM or Receiver.
Connect RX pin to your 57600 baud telemetry TX pin on Pixhawk/APM
Connect Pad5 to your HoTT receiver’s telemetry input.
If you wish to power it from Pixhawk, It’s ok. This would be the connections then:
Telemetry connector(of your choice), Pin1 (red wire) – goes to VCC on the device
Telemetry connector Pin2 goes to device’s RX pin
Telemetry connector Pin6 (last one) foes to device’s GND
Pad5 on the device, is connected to you HoTT RX’s “T” input.
This is an example of a possible connection: Usually, people connect it in paralell to another Mavlink device, like OSD or radio, so there is no need to purchase a DF13 connector.
note that the device comes without wires, I assume most people do have a old servo cable, and are better off installing the length actually needed.
If HoTT display (in the mode that display text) says NO MAVLINK … check mavlink
If you only see mode, no other info – check the parameters below, used to tell Ardupilot how often to send the different messages as suggested below:
SRx_EXT_STAT =2 =2Hz battery voltage, current and capacity GPS,fix .RAW GPS position, velocity, altitude
SRx_RAW_SENS = 2 gives 2Hz pressure, and temperature.
SRx_POSITION =2 position mixed with accelerometer & barometer data
SRx_EXTRA2=2 heading, baro altitude, climb/descent rate
A quick demo, switching between 8 modes using a servo-tester. The TAU640 in this video is set for outdoor use, and does not show the full advantage of Ice&Fire modes inside.
What you get:
A microcontroller on a small PCB (18x33x3mm) with soldering pads. Preprogrammed with 8 different modes as in this video, or up to 10 custom modes (as ordered).
The circuit works on 5v, uses less than 10mA. You can connect it using 3 wires, just like a servo)
The modes are selected using a knob on your transmitter, PWM decide mode, just like a servo position.
Serial data, is sent from the device to your FLIR device using one wire – (assuming you have common ground)
The common modes in this test video shows 8 modes I’ve found very useful.
What you need:
FLIR TAU ,TAU2, or QUARK thermal core.
For TAU, “Wearsaver” helps a lot. – It offers big soldering pads for connecting to the Hirose 50p connector. RX(pin2)
For Quark , you need to connect the serial signal to pin 15 of the Samtec 60 pin – connector. or to the breakout board, if you that.
Connect PWM (white wire) from your receiver to pad9 on PWM>FLIR device
Connect “-” (black wire) from your receiver to GND on the PWM>FLIR device
Connect “+” (red wire) from your receiver to VCC on the PWM>FLIR device
Connect pad8 on the device to your RX pad on wear saver, thats solder pad with green ring in the picture below.
Connect ground and +5v to TAU (black and red pads in picture below)
Finally, for information only:composite video out is on the yellow pad, and video ground on the blue pad on the TAU wearsaver.
Default mode configuration is:
1, white hot, no zoom , spatial threshold gain 34d.
2 white hot, 2x zoom, spatial threshold gain 34d.
3 Black Hot, no zoom , spatial threshold gain 34d.
4 Black Hot, 2x zoom, Spatial threshold = 9d
5 Fusion,no zoom, spatial threshold gain 34d.
6 ICE & Fire, no zoom, spatial threshold gain 34d.
7 Rainbow, no zoom, Spatial threshold, Gain = 34d
8 ICE & Fire, no zoom , Spatial threshold 17d
You can output a PWM from an autopilot, controlled by GCS, having any GUI you prefer. – Or , if you are will be controlling the PWM directly from a RC radio, you do not need a rotary knob with steps, it’s perfectly easy to hit desired mode even with smooth knob due to the quick visual change, and equal “distance” between modes.
Due to the proven vulnerability of current telemetry modules, I’ve developed something significantly stronger.
The source is not open, because it’s not real strong, certificate-based encryption, that allows end-user to replace, create new certificates. One advantage of doing it this way, is that you can purchase more radios and add them without having to reprogram all.
The secrets are permanently stored inside, and opening the source would give glues of possible attack vectors. I intended this to be a long time viable, secure solution.
Still – the owner have the option to get more radios that will work with his private network.
Fully compatible with all ground station configuration tools. All the common AT commands and parameters are there, there’s even a NetID that will let you make different networks within your encrypted network – should you wish. Example, if you have 4 CryptoTelemetry radios, you can have 3 in different UAV’s , all have the same network ID, and will speak to the same GCS, typical use is “one at a time”. Or you can set two radios with NetID different than the others, and use two GCS and two UAV simultaneously. – Note that no non-CryptoTelemetry radios will be able to communicate with these radios.
Locked down firmware, even if one malicious customer purchased it for analysis, it would be hard to learn anything from it. – Then it would take some time to find your encryption key.
Personal encryption key. (most tend to be 11digits) Only the customer will have the key, it is NOT stored here. To order more radios for the same network, it’s essential to provide the key so a properly encrypted firmware for your radio can be generated.
Your radios will operate in your network, no one else will be able to see the data, or encrypt without some extensive cryptanalysis and hacking.
Encryption can be disabled by disabling ECC – radios enter then a transparent mode, which is 2x the usual ECC data rate.
Efficient; the data rate is the the same as ECC, (half of the non-ECC speed.)
ECC (Golay24) is still active, for every 12bit , up to 3 bit errors can be corrected.
Delivered on standard, authentic, genuine 3DR telemetry radios.
If customer provides radios, it can be flashed onto a several other/compatible radios.
Reversible – should this method be obsolete one day, it is fully possible to convert these radios to run official 3DR provided firmware.
I am using this firmware for all my commercial operations as well as hobby flights, it is well tested.
Get your radio reprogrammed with CryptoTelemetry ($85):
Buy new original 3DR Radio with CryptoTelemetry ($135):
My professional background is network and Internet security, I quickly discovered the huge risk of an hostile takeover of UAV midair.
My experiment is based on 3DRobotics telemetry radios. but works with many more radios, based on the same, open, solution.
Please note that this is not a security risk of Ardupilot project, ArduCopter, ArduPlane is *not* to blame. You may get an idea that some changes should not be allowed while armed, but that’s not a proper solution. Having all the options we have, after all, GCS is a device to be trusted, and the primary control during a auto mission.
Radios lack proper security, mostly due to limited processing power for proper encryption. We are left with an simple attempt to secure the data, which is very easily worked around.
The open nature of the project, makes it impossible to truly protect the transmitted data. The radios do not have space & processing power to use public&private certificate based verification of data, also we would need a simple and a method of letting users selv-sign/generate such certificates for as many radios they needed in a network.
The current attempt to secure the transmission is based on radios dropping packets branded with different NetID- and the frequency hopping pattern to be seeded by the NetID.
So knowing or guessing one UAV’s (or companies) NetID, (provided it’s even changed from the default one) , enables anyone to send packets that are perfectly valid on the network.
To verify the theory, I needed an experiment:
I created a specialy crafted firmware for the stock telemetry radio, it proved to be a trivial task, Let’s call the module for BlackSheep, it have the following features:
Automatic sniffing of nearby NetID (as we know, the user-set NetID is also used to seed the frequency hopping)
When it finds valid packet with NetID, it learns active frequencies, and changes it’s frequency hopping to the pattern of that particular NetID – locking in on it. – whole process takes ~1second.
By connecting BlackSheep to any GCS, we have instantly a valid connection to a nearby operating UAV.
Hijacking the drone in real life.
We can assume a low-tech drone hijacker would do it by running a GCS and just do it manually. An intermediate hacker would use scripts with MavProxy, or clicking around in GCS software – but the optimal solution, is a predefined set of commands used by a modified GCS for easy map interaction.:
This is what an takeover looks like;
pointlessly evil hijacker could just disarm the drone midair or send MAV_CMD_DO_FLIGHTTERMINATION – but that’s not the goal here.
send, and repeat a few times: SR?_* = 0 – disables all telemetry output from AP , make the radio go silent. This will also reduce amount of packet collisions if we have 3 radios operating. (UAV is the one occupying most of the radio time) – now the victim GCS operator does not get any more updates.
Then we set all control FLIGHTMODE_? to AUTO or Guided (by preference), and disable FS_Throttle and FS_GCS , CH6 and other programmable options are disabled. The pilot with RC can’t do anything anymore.
Enabling SR?_EXT_STAT – gives the hijacker RAW GPS data, altitude, speed – this data is usually not visible on a GCS, so the victim can’t see it – but hijacker knows where the UAV is.
Uploading a mission, or Guided mode instructions sends the UAV to wherever hijacker wants – victim have no valid input, and cannot see it in GCS, all he gets is Mavlink heartbeat.
Finally, for the extra evil touch hijacker can inject Mavlink MAVLINK_MSG_ID_GLOBAL_POSITION_INT packets (as if autopilot was sending it) with proportionally incorrect data, so we could get the victims GCS display and log the real movement, with actual speed, but in different direction, misguiding as to where the UAV went.
I skipped a few trivial steps, like setting higher cruise-speed, and few platform dependent commands – but the short summary should be frightening enough.
What can be done to prevent such hijacking ?
Fly without telemetry radio, reducing mission control and control redundancy, not good.
Use cellular network to get TCP or UDP control, limited coverage.
Use wifi, very poor range.
Satellite modem, expensive, very low data rate, often ~2400bps
Continue to develop open solutions with hardware limitations that limits us to very simple security solutions, like the one in use today – very easy to circumvent.
Use customized, specialized, closed solution that offers good security, it is not proper certificate based encryption, but rather an odd, but very effective scrambling. Effective mostly because the firmware is locked down, and not easy to analyze.
Telemetry radios , 433/900Mhz are great, most aviation authority approved approved flights , professional or hobby, are within VLOS, where these radios perform great.
The fact the source i open, is not a drawback, but a strength. It allows people like me to detect security vulnerabilities, like many other can do, and documents them, or protect against them, so others cannot silently abuse them, without users understanding what’s going on.
It’s long time since last time I published a new buildlog/project.
My new car needed a decent stereo, it had a “iProduct” interface, but I needed something better.
Unlike my previous car computer projects, I did not wish to install an amp + carputer in the trunk, and run VGA,USB and speaker cables forth and back. I wished to have everything integrated in the dashboard.
The idea was to build according to ISO standard, then use a Toyota<>ISO-harness adapter.
Using the ISO-Toyota harness and integrating an amplifier also makes it easy to control the car’s active sub kit and active antenna, without modification.
Analysis of the resistive buttons connector in Avensis
This is the control module interface documentation, a RJ45 connector between computer & external controls.
This is the control panel itself, controls power mode (always on/always off/follow ignition) camera select and reset switch built into the ashtray,(usually closed)
Lilliput 629 (7″ touchscreen) disassembled
The resulting analysis of the proprietary connector of the display controller. Cables with proper motherboard connectors are now soldered directly to it.
The Lilliput needed to have some shielding cut off to fit better inside the (far from perfect) Double-DIN box
The display’s edges needed to be padded, to prevent the double-din frame from “touching” the touchscreen area.
Display, and display controller installed, IR sensor and buttons relocated.
Don’t repeat my mistake, while waiting for this motherboard, I built proper 2,54 connectors for VGA,USB,Audio and so on, just to discover the pin headers on this motherboard are 2.0mm !
Circuit for relay control. (provides power to display, amp, external amp(active sub), and antenna output).
Motherboard+PSU installed, the hard-drive is below motherboard
The amplifier is now installed (built around a TDA7850 (4x~50W) plus BA3121 ground isolation amplifiers.).
Radio module installed, The blue cable in the control port simulates the “usual” control-panel configuration for lab-use (follow ignition) and use reverse camera
That’s it, ISO connector compatible device. with internal radio, and amplifier.
Installed in car, displaying reflection because it’s off.
I also modified the “hibernating” screen with a custom logo – removing windows logo feels good, looking forward to the release of Centrafuse for Linux.
This mod gives S-Video output, and SPDIF (digital audio) output, plus removes the need for the original audio+video cable
Why: XBOX usually delivers Composite Video output + Stereo output. With an “Advanced” cable, user can enjoy RGB video & optical SPDIF.
I wanted higher video quality then composite video delivers, and my projector (as most projectors) does not support RGB.S-Video is better then Composite, mostly because it uses 2 wires (Luminance & Chrominance) , instead of just using one wire, as Composite does.
This mod allows XBOX to boot & work just fine without the original audio+video-cable connected.
The original cable is still working after modding this way.
This should not be necessary to say, : This voids your XBOX warranty instantly 🙂
+The original connector/cable will still work as before.
I skip schematics – here goes the pictures… they say it all:
Finding the signals/connecting to them:
This picture shows the solder-side of the XBOX motherboard, where the video+audio connector is mounted.
RED long wire, goes to the center of the SPDIF connector.
WHITE wire, is the S-VIDEO Luminance line
GREEN wire, is the S-VIDEO Chrominance line
The thin RED wire that connects three solder-points , connects two sensing-points to GND, When this two points are grounded – XBOX is cheated to believing that the original cable is connected, AND SPDIF digital audio output is enabled
TRICK: Usually – I would also need to connect the Y-GND & C-GND lines too. XBOX is fortunately well build and uses common ground for all I/O lines, and therefore, I will use the ground from the XBOX chassis instead..
Now , The connectors:
This is the inside of XBOX’s rear shielding plate.,
I drilled some holes, and inserted:
One female RCA connector for the SPDIF
One female S-VIDEO connector
Both connector’s shields are soldered to the XBOX’s chassis-shield (perfect ground source, XBOX motherboard is very well grounded at several points)
Finally , Connecting the connectors:
*1 = S-Video connector. There are two more pins beneath the two you see. These pins are connected to ground.
*2 = SPDIF, ground connected by soldering shield to the XBOX shield
HINT: You can see I removed the tin-fan-grills that were between the fan and the plastic fan-grills. I did it to improve air-flow.
A better alternative :
Using shielded cables might give higher quality – I did not see any difference, but here’s some pictures of this mod with shielded cables…
Night diving and wreck diving requires a good torch. When I asked for advice on buying a torch, most divers I told me that “30Watts are great , 50Watts are insane , and anything above is not really necessary…”
If it’s worth doing, it’s worth overdoing. I started with interpreting what they said , It sounded to me like this: “30Watts are OK , I have it because I could not afford the 50Watts , anything over 50Watts is what I would like to have”
So… what I “needed” was :
225Watts … (3 x75Watt bulbs)
battery time of at least two hour at reasonably high intensity…
>20Khz PWM (Pulse Width Modulation) to keep high efficiency and no noise.
Internal 28Volt DC-DC converter to improve efficiency of Power MOSFET’s .
Multiple bulbs (3), just in case one dies – there are still two left.
No disassembly required for charging.
Nice software with SOS and maybe a bottom-timer.
Self adjusting intensity (not implemented yet)
Low battery warning and battery capacity prediction. (not done yet)
So , the project resulted in:
Acrylics pipes with 22mm acrylics ends , with O-rings , 4Mhz RISC Microprocessor that works at 4-5 volts , 28Volt DC-DC pump , 2 optically isolated PWM outputs that uses the 28volts to control 50Ampére low-drop power MOS-FET’s so fast that the MOSFET’s does not require any cooling as they “never” are in linear state. A 2×16 Character LCD display had to be added.
There are no moving parts, the 3 buttons and on/off are magnetically controlled and does not represent a weak point (or should I say leak point ?)
here is the battery case : two 12Volt 6,5Ah batteries in parallel gives 13Ah ! (could be 2×7.2Ah , but I 6.5Ah was all I had).
Here is the torch ,
the display is showing voltage and intensity. as soon one bulb is 100% on , the other 2 starts helping , that’s to distribute the bulb-burn-time so their life length will be different. those are 3x50Watts “Osram Decostar” (1×10º , and 2×24º) halogen bulbs ,just because I did not got any 75Watts , of course , the electronics will handle 3x75W (225Watt)
The LCD display is back-lit , (green/blue) , and looks very nice under water. Now booting …
because of the massive intensity of the light , the camera could not do better , the LCD is invisible , It’s normal daylight in the room but “seeing” this bright light source , the camera made this picture so dark.
The design/circuit should always be treated as freeware, you might build as many as you like , even for your friends.
The author (me) must always be credited as the author.
The compiled program is here. , It is possible to buy preprogrammed controller from me.
The schematics: (right click the picture below and “save target as”)
A little description , it should be everything you need to know:
U$3 is the LCD connector , any HD44780 compatible LCD goes , at least 2×16 characters.
PADLAMP1 is the pad (output) for lamp1 , padlamp23 is is for lamp 2and3
JP2 is the switch/button connector
use IRFZ44 or better power MOSFET (BUZ 11 is used on schematics by accident) – they are pin-compatible.
Q: Do you have the container plans ?
A: No ,I just found some material that would fit the batteries worked on it.
Q: Is there a PCB layout ?
A: Yes , I designed a two layer PCB ,but never etched it.
Q: Where did you found the O-Rings you needed ?
A: A hardware store sold them as meter-ware with a special glue, then I made the O-rings I needed.
This picture shows the two dongles that are necessary needed , the big one is the controller , with infrared connector (for wireless glasses) & the other connector for wired glasses. This controller needs +5Volt at pin #9 in order to work.
Some graphic adapters deliver +5 volt @ pin#9 , Nvidia’s reference-design based adapters does not. you will also need external +5volt if you want to use the stereo glasses on/after a KVM switch or with an extension cable.
This is when you need the power adapter , the smaller one , it’s gutted on this picture , but it’s just a PS2 keyboard male+female (pass thru) adapter that connects between the PS2 port an keyboard in order to leech some power , and then deliver it to pin #9 in the smaller VGA-VGA (DSUB15) dongle.
I thought that 2 adapters were one too much , so I chopped off the PS2/PS2 connector cable from the small dongle and found that both wires inside were connected together to +5volt (the bigger dongle is already connected to GND by the shield , and R,G,B-ground.
Then I drilled a hole in the dongle for the cable (can be seen on both pictures)
The black wire with the red shrink wrap and red wire in center is the one , it goes straight for the second idle drilled wire-pad on the dongle’s board.
+5 Volt delivered , and only one dongle needed – less cable macaroni.
I like the product , it’s one of those gadget’s you can buy and NOT regret it the day after – the dongle is of high quality and does NOT cause poor picture quality at high resolution/refresh rate , I just removed it for a cleaner setup.
You can also use USB connector to get the +5v .