Electronics > Projects, Designs, and Technical Stuff
Piezoelectric sensors, Fm trancievers and more.
StillTrying:
"The decoder needs three complete transmissions to verify the data and to switch on/turn off his outputs."
I see.
"If i install the encoder/decoder i can only manage to get repeatable results if i take a significant pause between the taps.
So i assume the en/decoding takes up the time."
By my calculation with 3 transmissions it takes about 1/23 sec. to change the state of the decoder's output, so the max. rate of transmitted pulses is about 11 per second, I assume that's fast enough.
It's not clear to me from the HT12A/HT12E data sheet what happens with the 12.3 bit pilot/preamble time when the HT12A is in continuous transmission, which might slow the max change/pulse rate down even more.
Wigo:
The fastest pulses would be arround 6ms (rounded down, calculated they are near 6,6 ms) so the ht12 would be too slow, but that rate would not be needed on every sensor.
But at that frequency i run into other problems.
The RC network that is used to elongate the pulse to allow a sucessfull transmission would also be to slow. (But that can be changed)
But i think that with that short pulses i need a better way to distinguish between the pulses and oscilations of the piezo after a pulse. Thats definetly something i need to meassure.
I think i takled this a little bit too fast, interms that i was racing to get everything implemented. Till i can take the next real life experiments i have a few months time, so i can troubleshoot and reevaluate the whole thing.
The analogue circuit is nice in terms of power consumption, but it gets more and more complicated and open for failures.
If i go the uC route however i could establish a good an reliable communication and i can, if i use trancievers, establish a just send on request policy.
I have ouch to think about.
StillTrying:
"The fastest pulses would be arround 6ms (rounded down, calculated they are near 6,6 ms) so the ht12 would be too slow,"
Yes the HT12E is taking at least 25ms to send just one frame.
This no encoder/decoder might be worth a read while you're thing about it.
https://www.romanblack.com/RF/cheapRFmodules.htm
Wigo:
--- Quote from: StillTrying on June 05, 2019, 04:22:58 pm ---Yes the HT12E is taking at least 25ms to send just one frame.
This no encoder/decoder might be worth a read while you're thing about it.
https://www.romanblack.com/RF/cheapRFmodules.htm
--- End quote ---
Thanks for the link. It was a good read and something worth to consider to use. I have the exact same RF-Modules as used in the article.
Now i have to turn on my calculator, fire up google and start a new planing phase
Wigo:
Just a quick update.
I am currently in the process of redesigning the whole project.
As mentioned above the purely analog sensor/Tx circuitry is to slow to capture the (possibly) fastest pulses i have switched over to using uC for the sensors as well.
By now i am evaluating what uC i really need for that task. And it depends on how i will, can implement some sort of identification for the sensor it self. I really like the idea of using Dip-Switches for setting the ID/Adress of the Sensor and given that i need a maximum of 10 Sensors connected to one Node i could use the first 4 "bits" to specify the Adress of the Node it self and the last 4 "bits" to specify the Adress of the Sensor.
That would give me a total of 15 Nodes that could work independently with each Node having up to 10 Sensors connected to it. (If i have not miscalculated something).
I want to use Dip-Switches over "Hardcoded" Adresses because that would eliminate the need of tieing the Sensors to the Nodes permanently.
The second path i am following is that i consider switching from a one way communication to a complete two way communication. That would give me the ability to time the transmission of the Sensordata to the node (so that i do not have overlaping signals) and i could easily implement a powersaving mode and a reset. It would also lower the time i use the frequenzy as ther would only be a transmission if it will be requested by the user.
And the third path is that i am trying to build a test system, or a simulation system, to test various settings of filters and timing at home. I only need one more realtime test with the old analoge Sensor to get a good meassurement of the oscillation of the piezo upon impact to recreate it at home. But i have to decide if i want to do a realworld modeling (in terms of the forces provided) or a simplified modeling. Maybe i can even recreate the oscillation with an AWG but first i need to get a real world measurement.
I will keep you updated.
Christian
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version