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
Showing posts with label rfcomm. Show all posts
Showing posts with label rfcomm. Show all posts
Sunday, December 20, 2015
Thursday, January 3, 2013
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)
(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.
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.
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
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...
Subscribe to:
Posts (Atom)