If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.
Special Thanks To:
Aaron Holmes
Aaron Wheeler
Adam Horden
Alan Scrimgeour
Andre
Andrew Haynes
Anonymous000
asabase
Austin Weil
barney
Barry
Bert Hickman
Bill Kukowski
Blitzorn
Brandon Paradelas
Bruce Bowling
BubeeMike
Byong Park
Cesiumsponge
Chris F.
Chris Hooper
Corey Worthington
Derek Woodroffe
Dalus
Dan Strother
Daniel Davis
Daniel Uhrenholt
datasheetarchive
Dave Billington
Dave Marshall
David F.
Dennis Rogers
drelectrix
Dr. John Gudenas
Dr. Spark
E.TexasTesla
eastvoltresearch
Eirik Taylor
Erik Dyakov
Erlend^SE
Finn Hammer
Firebug24k
GalliumMan
Gary Peterson
George Slade
GhostNull
Gordon Mcknight
Graham Armitage
Grant
GreySoul
Henry H
IamSmooth
In memory of Leo Powning
Jacob Cash
James Howells
James Pawson
Jeff Greenfield
Jeff Thomas
Jesse Frost
Jim Mitchell
jlr134
Joe Mastroianni
John Forcina
John Oberg
John Willcutt
Jon Newcomb
klugesmith
Leslie Wright
Lutz Hoffman
Mads Barnkob
Martin King
Mats Karlsson
Matt Gibson
Matthew Guidry
mbd
Michael D'Angelo
Mikkel
mileswaldron
mister_rf
Neil Foster
Nick de Smith
Nick Soroka
nicklenorp
Nik
Norman Stanley
Patrick Coleman
Paul Brodie
Paul Jordan
Paul Montgomery
Ped
Peter Krogen
Peter Terren
PhilGood
Richard Feldman
Robert Bush
Royce Bailey
Scott Fusare
Scott Newman
smiffy
Stella
Steven Busic
Steve Conner
Steve Jones
Steve Ward
Sulaiman
Thomas Coyle
Thomas A. Wallace
Thomas W
Timo
Torch
Ulf Jonsson
vasil
Vaxian
vladi mazzilli
wastehl
Weston
William Kim
William N.
William Stehl
Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Registered Member #14
Joined: Thu Feb 02 2006, 01:04PM
Location: Prato/italy
Posts: 383
I'm experimenting with wireless data trasmission (in particular wind-turbine-related) as i stumbled upon the cute TLP/RLP434 cheap'n'easy transmitter-receiver pair. The first step was to choose the working protocol, and i selected the a pulse-width modulation one, easy to implement and with reasonable error rejection.
The protocol is chosen looks like that:
Header: one 400 and one 500 us pulse spaced 100us apart, if the receiver fails to recognize one of those, it goes back to idle state.
If the header is correct than data is sent in groups of 8 bits (1 byte) with 9 100us HIGH pulses and 8 spaces with variable (100 or 200us) spacing
__ In particular: | |__| = means 0 __ | |_____| = means 1
after a byte is finished the pulse spacing (600us or 400us) determines if the next action is to wait for the 1st bit of the following byte, or going to leadout. In case of leadout a HIGH pulse of 300us is expected in order to confirm data validity, if this fails, data is rejected.
This was successfully simulated in proteus 7 with two pic16f88, (PicBasic 2.5 receiving and displying on LCD)
After that the next step was to test the modules. In particular i programmed a pic16f88 on breadboard (I know, it gives ugly capacitive effects and affects risetime, in fact the signal on the receiver side was even better than the original!!!, but first ... no matter, keep on reading), connected it to the transmitter with a 17cm wire antenna (1/4), and connected to a 12V SLA (5V regulator on the pIC). On the receiver side i connected a 5V power supply, and no antenna to the module. I set up the oscilloscope (optical memory) with on CH2 the original and the CH1 the received signal, with trigger on CH2 (see photos).
The signal looked ok with no significant changes except a little delay (40-50us) between the two signals, imputable probably to the modulation (not the speed of light, such delay would mean 12Km distance), but not anything to worry about.
The real problem was that during the pause between two trains (500ms) after 100ms the signal goes crazy with random junking that stabilizes after a single pulse is received, forcing me to add a pulse before tha header to "clean the junk" (this pulse is rejected by the receiver because the lenght isn't conform with the header) .That fact forced me to keep the transmitter close to trigger the scope (to avoid random-triggering using, defacto, the original signal to trigger the scope). Today i repeated the experiment, accidentally powering the receiver with 10V (dual supply 5+5V), but initially i dind't noticed that. I was happy to see that there was no junk, so i tried to trigger the scope with the receiver, to test the range. The range is good in the home, even outdoors (except if i remove the transmitter antenna). In fact with the antenna removed the scope was it "waiting" state with no random junk coming from the receiver, and it restarted receiving when i plugged the antenna in. After that i noticed something strange, on the scope. The pulse height was 5 divisions with 2volts'per'division, 10V actually. I realized that the module was powered with 10Volts with no damage, and better performance!! The datasheed of the RLP434 says that the maximum rating is 6V, but the module doesn't fry at 10V and works even better!!In fact powering it with the rated voltage or less makes it go crazy, 10V instead it is very stable.
What do you think, may be a datasheet error?
(As I write the transmitter is transmitting the string "Hello world" since an hour approxymately, and the receiver is receiving it, in form of bytes)
The final destination of this project is to transmit from a small wind tower a packet of data consisting of: wind speed (2 bytes), turbine rpm (2 bytes) , alternator voltage (2 bytes),current from a shunt (2 bytes) and battery voltage (2 bytes)
obtained from the onboard ADCs and counters of the PIC16f876a (already simulated it). All this will be displayed on a 4 lines LCD (i want the sistem to be stand-alone, not PC-dependant)
Tell me your thoughts an suggestions.
The images show the original and the copy, guess which one is the original and copy. It is easy to recognize a byte. The third image is the receiver alone powered with 10V (i have to clamp the signal to 5V or it will fry the PIC port)
EDIT: actually the string is DATADATADATA
decode it yourself if you want , the first is 0-0-1-0-0-0-1-0 -> %01000100 = 68 => ascii "D"
Registered Member #27
Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058
If the datasheet says 6V then there is a reason for it. Often the reason is not easy to understand. For example a 74HCT14 chip is rated for 5V, that does not mean it will fail with something else, it just means it needs 5V for the datasheet to be valid and to be compatible with TTL.
Without knowing why the datasheet says 6V you don't know if it is safe to run it at 10V, it may shorten the lifetime or maybe make it fail instantly on a hot day, you never know.
When it comes to the "junk" your protocol and reciever must be able to handle any "junk". The frequency is shared with any any number of devices that might be around and the receivers are prone to emit junk when they don't get a strong signal, which they don't if you stop transmitting. You must stop transmitting at regular intervals to make room for other devices to communicate, if not you are probably breaking some law. If you don't want to make a strong error detecting and correcting protocol you need to get more expensive modules with the protocol built in.
In this case you could probably add a 16 or 32 bit CRC to your message and reject those that contain errors and you should be fine.
Registered Member #14
Joined: Thu Feb 02 2006, 01:04PM
Location: Prato/italy
Posts: 383
Bjørn wrote ...
If the datasheet says 6V then there is a reason for it. Often the reason is not easy to understand. For example a 74HCT14 chip is rated for 5V, that does not mean it will fail with something else, it just means it needs 5V for the datasheet to be valid and to be compatible with TTL.
Maybe this is one of the reasons, in fact the output signal is 10Vp-p, forcing me to use a divider or clamping for the pic. The protocol is able to handle the junk. I added the "junk cleaning pulse" to stabilize the receiver, that rejects anything different from the header. During the transmission the data looks quite good, and goes crazy only 100ms after leadout.
Registered Member #27
Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058
That is quite typical of those modules so nothing to worry about.
The input clamping diodes in the PIC are very sturdy and usually a series resistor is all that is needed to accept almost any kind of input as long as it is not one of the open collector inputs.
Registered Member #27
Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058
You calculate the CRC for your message and add the bytes to the end of the message. Then your receiver can calculate the CRC for the received data and compare it to the received CRC, if they don't match there has been a transmission error and you just wait for the next packet.
If errors are rare you might not need a full CRC but use the sum of all bytes or something similar, it will still detect all packages with a single bit error.
Registered Member #14
Joined: Thu Feb 02 2006, 01:04PM
Location: Prato/italy
Posts: 383
The bytes transferred are a total of 10, 12 with the 16-bit CRC, the problem is to do the computation.
The errors are quite rare,
A 1-0 swap is quite difficult, since it is a PWM protocol. and pause differences are very noticeable (100us = 0, 200us = 1)
, so a byte swap is difficult. A spurious pulse ending the byte prematurely will de-phase the receiver, obtaining a wrong end-of-byte signal, causing the system to reject the whole packet. There is a possibility that the receiver would mistake the end-of-byte signal for with a 0, but then it would wait for the end of byte, that eventually will lead to the rejection of the packet.
Maybe a simply xor checksum will be enough with this protocol, with this datarate and with the data not being important (i don't need to trigger a bomb , se an error will not be so important, even remote )
Also i can use the checksum as a crude crittography, XOR-ing the bytes, and the checksum with a reference byte
Registered Member #14
Joined: Thu Feb 02 2006, 01:04PM
Location: Prato/italy
Posts: 383
I'm designing the final stage of my project, embedding the TLP on a PCB board, but i have a doubt. Should i use a BNC connector and a coax cable to connect the board to the antenna? Do i risk some power losses in the cable? It is convenient to use a simple wire for connecting to the antenna? Thanx for your help
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.