Multirotor thing

Project X

- Motors: Turnigy Multistar Elite M4112 320 kv (~145 grams each)
- ESC: 30A ZTW Spider (OPTO) w SimonK
- Props: Quanum CF, 14x4.7
- FC: Navio+ on Raspberry PI2 (GPS, LTE, WiFi on board)
- Batt: 2x Turnigy Nanotech 4S, 4.4 mAh (~65 C)
- Frame: 610 mm, Turnigy Talon v2 w. octocopter plates and extractable landing-gear
- RC: FrSky, 12 ch. (Taranis X9D Plus w L9R receiver)
- FPV: TX: 5.8 GHz, 200 mW (Boscam clone)
- RX: w antenna diversity. (RX/TX w matching cloverleaf antenna)
- Camera: Mobius actioncam (lens type "A")

Total weight: 3300 gr
Flight time: ~14 min

Project H

Motors: Turnigy NTM-2826 1000 kv
ESC: 20A Afro (OPTO) w SimonK
Props: Quanum CF, 10x4.7
FC: CRIUS AIO (w. GPS, Bluetooth)
Batt: Multistar 4S, 16000 mAh (10C)
Frame: 375 mm, combined from Turnigy Talon v2 parts
RC: FlySKY 6 ch. (FS-T6 w. matching receiver)

Total weight: 2400 gr
Flight time: ~15 min

Checked with http://www.ecalc.ch/xcoptercalc.php


TODO:

project X (navio)
- 3d case http://www.thingiverse.com/thing:868826
- 1x stabilizing boom. 560mm, dia. 14mm
- RPI cam for streaming over 4G
- 1x 4400 mAh nanotech 4s for symmetry
- 3DR telemetry radio-modem for backup


project H
- fuselage. 2x 2.5 mm, 550 x100 mm CF sheet
- OSD solution for analogue video stream
- FrSKY telemetry receiver: X8R
- skyzone FPV goggles
- head-tracking gimbal (mobius)
- hauppauge VDR

calibrating an rtl-sdr with PMR

The cheapness of the dvb-t style SDR comes with a price of it's own - an internal oscillator has not the highest possible precision and it's oscillating frequency tends to float a bit as the device gets warmer during an operation.

Thankfully there are ways to somewhat mitigate this issue in SDR software by setting the crystal's ppm offset. But how to determine the required value? Well, by comparing the SDR capture to something own like the PMR frequencies.
Via this simple method I found out the the freq. correction value for my dongle: -107 ppm.

graphing sensor data

What's the value of collecting and logging sensors data if no graphs are produced? (a rhetorical question :)

As with many things, graphs can be generated in very-very many ways. I preferred using RRD until I found an excellent alternative - dygraphs!

Here are some examples of how I've utilized the dygraphs powers:

Electricity consumption measured from the meter directly.

The "idle" consumption is from the inverter-pump, refridgerator, aquarium lighning+pump, home HiFi and couple of connected wall-warts.

The peak comes from coffe-kettle and some breakfast preparations. 

Celler's temperature and humidity measured by a HopeRF TH01.

All three graphs data is gathered by (2) AVR microcontrollers and stored in an old EeePC from Asus running a pure debian Linux. 

Temperature measurements from the my wireless weather-station's outdoor unit.

Domesticating arduino pro mini clone

DIY Arduino ISP

At some point I realized that it was time to move on from convenient prototyping boards to more aschetic ones to both save in energy consumption and in money. As I've always wanted my hobby projects to be small in size I spotted those cheap arduino pro mini clones on eBay that suited my search criteria. (Search for an atmega328 running on 3.3V at 8 MHz. Anything under 3 EUR will do - there are just too many of those clones to point out any of them separately)

Pro mini boards do not have an FTDI chip meaning that programming can only be done via an external programmer. As I didn't have any I turned one of the MINI-AT boards to an ISP. That was really easy - the hardest part being solving the wiring and connectors problem (PC signal cables are notoriously fragile without dedicated connectors on either side) since I needed the programming process to be repeatable with many pro-mini boards that might end up on my workbench.

The key to my problem was in finding a spare 15 pin connector I had salvaged from an old printer just recently. By cutting off the excess the connector matched perfectly with the pro-mini 12 pin headers I was about to re-flash. To the other side of the programming cable I clamped a 6 pin type RJ11 connector and hid the wiring, status-LED's and an entire AT-MINI board inside a small telephone connection-box. (I had to take two extra connector-wires from another box since these are all shipped with just four wires. Same trick with the RJ11 plug - two extra metal tooth were needed from another connector-plug.)

Wiring

Programmer   -->   pro-mini board

VCC (+3.3V)   VCC
GND                GND
SCK                SCK
MISO              MISO
MOSI              MOSI
SS                   RST

PS! It is advised in forums to add some caps for the programming to be successful. I ended up with adding just one balancing 100uF 16V electolytic capacitor between VCC and GND. Nothing more, nothing less.

Uploading the code

To upload code via an external programmer one has to select 'Upload Using Programmer' from an arduino IDE (File menu) or press a keybord shortcut CTRL+SHIFT+U

decoding wireless thermo ASK signal

A weekend project

I happen to have an old and reliable (!) wireless temperature station with alarm clock functionality operating in an ISM band at about 433Mhz. The main unit has in capital letters "DENVER" printed on it but no model name anywhere. (Even after opening the casing I could not find any markings which could be used in google searching)

The company still produces similar gadgets (http://www.denver-electronics.com) and I think that the current models like DENVER TRC-1480 can be seen as a grand-grand-grand son of my unit :)

Features:

- up to two wireless temperature sensors (I've got just one)
- temperature sensor inside the main (indoor temp) unit with C and F conversion capability and memory option about min and max temp within some time (72h perhaps?) window.
- digital alarm clock with really annoying beeping sound ;) (never used)
- long battery life (batt replacement occures so seldom I cannot even recall how often in general. once per 2 years perhaps?)

Preparations

By tuning the an SDR to 433 Mhz and warming the outdoor unit's thermistor a bit between fingers I received loud and clear signal at 433.92 Mhz. To aqcuire the session samples to decode later I captured four radio transmissions (I was still warming the thermistor) and noted down the temperature readings on main unit. How? I just recorded with gqrx the entire bandwidth the RTL-SDR dongle was set to operate on (in this case 1.5 MHz) - quick and dirty but worked fine for this purpose).

To be able to start guessing about the data coding methods used, I had to zoom in to the demodulated (audio) waveform. This is OK since the high rates (48000 Hz) of audio sampling and relativey slow datarate of the device.

As (AM) demodulation was done by gqrx already I just had to record the audio-sample (note the record button on the right pane)

Waveform analysis

From the waveform it is visible that a RZ coding is used. The pulse indicates a start of the next bit and the length of the pause between pulses indicates either the bit is 0 or 1. If the pause is longer (approx 4 x 1) then it signals the end of current message. (reading direction: LTR)

(click here to listen to the recorded sample. it's in FLAC encoding.)

The payload consists of 24 bits. First byte indicates the sensor ID, second byte is the full decimal of the temperature measured (in Celsius) while the last byte's lower nibble indicates what's behind the comma. 

For example: 10000011 00011001 10001000 translates to (according to my interpretation): The latest temperature measurement by sensor with ID= 10000011 is 25.8 degrees in Celsius. (And besides, sensor's battery is OK)

The message is repeated 24 times within a single transmission which is in total about 2.09 seconds long.

Data processing

Audacity has a nice feature of exporting the sampled data to a txt/csv file so I just had to do a trivial (!) textfile processing to get the desired bitstring. No need to process the structred audiofile (wav for example) via custom (python) scripts. Nice.

Tip: From audacity, on selected portion of the waveform, choose from menu: Analyze -> Sample Data Export... and now tune the selections to your taste. I selected 'all headers' and 'indexed sample format' options. 

I must admit that the offline signal processing was a lot easier than I'd expected thus given the right tools and appropriate hints it should'nt be a problem for anyone.

The exportfile (pure ASCII text) has a very easy format:

A sample sequence number, tabulator character ('/t'), sample value in dB notation and newline character ('/n'). Armed with some scripting skills, it's easy to count, sum, detect etc. the dynamics of measured values and finally reach the goal by getting an easily readable/comparable bitstream.

Perhaps some additional notes to be added later...

  

discovering OBD-II

Every modern car has a diagnostic port called OBD-II (On-Board Diagnostics ver. 2) which enables external devices to communicate with the ECU - the brain of the car.

Well, if your vehicle is brand-new there is no real reason to peek under the hood but if it's a second-hand then one should be prepared to encounter all sort of problems used cars might run into... with the help of live data and logged failure codes the reparation just got a small step easier.

On eBay you can find cheap bluetooth OBD-II adapter (like the ELM327) that make a perfect match with any smart-phone with proper software installed on it.

I have an Android phone and there are quite many applications just for this purpose. Most notable perhaps is the Torque by Ian Hawkins.

As modern phones have an impressive assortment of on-board sensors, it makes it a perfect drive-computer and allows all sorts of analysis be made in real time and later on, based on collected data.


Just to name a few:

- engine load (%)
- turbo pressure (kPa)
- in-take air pressure and temp

- fuel consumption (l/100 km)
- speed by ECU
- throttle position

- acceleration
- speed, direction and position (GPS)

Software on a smart-phone nicely bundles it all together and is capable of keeping a log file with for example 1 second interval.

investigating the sdr world

Gqrx tuned to local FM station at 100.0 MHz

Hardware

The RTL2832U based SDR is a very capable little gadget that anyone can set up without having to spend too much on dedicated hardware.

I got mine ("mini digital TV stick" as written on the package) from eBay for about £15. It's yet another no-name USB DVB-T dongle with just suitable hardware combination inside.

Basically it captures raw RF packets and let's the PC software to decode/demodulate those. Thus exactly what an SDR does! Still, it's a hack since some undocumented chip features are used to make it behave like one. Great thanks to Antti Palosaari for discovering this! More on that subject can be read here.

Software

Firstly, I consider only Linux here and all my suggestions are based on that.

Depending on your operating system the support out-of-the-box varies a bit but there is nothing too serious to build all the necessary tools from tarball.

Seems that setting the system up on OpenSuse 12.1 means bit more work than on Ubuntu for example since one has to build some system packages to meet the GNU Radio dependencies that have not yet reached to the official repositories.

Waterfall shows some sensor activity

For beginning the Qt based gqrx application is really neat and as many instructions on the net I also suggest starting from this.

Later on you will find yourself discovering the gnuradio-companion IDE with a certain amazement bout how truly complex and fun the SDR world really is!

As the Elonics E4000 tuner can be  tuned from 52 MHz - 2.194 GHz it really opens up the radio spectrum for any hobbyist like me never minding the 161 Mhz band-gap starting from 1.098 GHz

Applications

After having scanned the radio spectrum over and over I started to wonder what else can be done with it. And thus I decided to try to decode the wireless thermo RF ASK modulated messages captured from the air.

Work in progress...

measuring energy consumption

1. Theory of operation

The energy meter used in our house is a Siemens ZMD120AMtr53 which capable of measuring 3x230/400V (e.g. industrial power) electricity consumption in preprogrammed day and night shift. The energy company charges less for nighttime usage (EUR 0.08 cents) and considerably more during daytime use (0.14 cents)

The meter has three ways of communicating it's readings to interested users:

•  dedicated DLMS port for programming and data readouts;
•  IR test diode pulses (each 0.2 ms long) with a rate of 10000 = 1 kWh;
•  via on-board LCD "graph" (regular users, simple inspection)

The formula for calculating present power consumption via short pulsing IR light is brought by the data sheet:

Example: Meter constant R = 1000
Power P = 36 kW
f-LED = R x P / 3600 = 1000 x 36 / 3600 = 10 imp/s

In my case, the meter was programmed to have the constant 10 times bigger to achieve more precise readings. Thus, once you have an impulse count in seconds, it's easy to calculate real-time power usage.

2. Selecting an IR sensor

A sample graph for 12h power consumption with RRD

There are several ways to detect IR radiation. Though some detectors might not be as suitable as others thus some consideration has to be made. Firstly, how far would you place the micro-controller? If the wiring will be considerably long (> 10 meters) it would be a good idea to use a sensor with an in-built OP amplifier to get a strong signal over the long wires. That's how I saw it and therefore a sensor TSL262R was chosen. If I would have planned to put the controller inside the same metal box where the meter was located, perhaps a simple IR photo resistor would have done the same good job.

3. Building a prototype

Prototyping is fun! Although I googled for some samples of other fine projects I came up with a more simple and straightforward solution. Firstly, as I formulated the problem very precisely, I ended up getting exactly what I needed. No additional calculations were expected from my 8-bit AVR microcontroller. It's quite the opposite I saw around. Thus I really count pulses and deliver the pulse count in selected timeframe to a logfile.

From software perspective, the key is utilizing the power of AVR chip's interrupts thus leaving more room for other interesting tasks.

volatile long pulseCount = 0;

// interrupt attached to IRQ 1 = pin3
attachInterrupt(1, onPulse, RISING);

and the function to perform is simply

void onPulse() {
 pulseCount++;
}