Search

Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

HM-TRP Radio modules malfunctioning?

Member

I don't know if its just a dud I have or what, but I made a system in which the PC transmits a series of characters to a microcontroller via HM-TRP radio modules.

What I notice is that even though the program on the microcontroller is supposed to continuously accept serial data with high priority, the radio module sometimes stops working at random times for about 15 seconds to a couple of minutes then starts working again.

I can verify this because when the modules work, both red and green lights on both devices blink at a high rate, but when the module attached to the microcontroller doesn't want to work, its lights are fully out but the HM-TRP connected to the PC is always transmitting.

Both radio modules are given 3.3V through LM1117 regulators and the power supply to the regulators are 5VDC. The voltage conversion to the modules from 5V is done by feeding the data in and out through 74HCT04 inverters.

Each module has a 220uF decoupling capacitor attached to it and has a 915Mhz helical antenna attached as well since the module runs at 915Mhz.

Is there something with these HM-TRP units that I'm not configuring correctly? Or is one faulty? or what?

Member

Because I'm making a lazertag game for a large number of players and a lot of data needs to be exchanged in a short amount of time. And I don't think 38400bps is fast enough.

What prompts me for higher speed is the fact that I need a long array of 3 bits to store bits representing which player shot the target and where. So for a 30 player setup, I need to send out at least 90 bits of data plus 8 bits for player and 8 bits for controller ID and 8 bits for checksum which equals 114 bits or 15 bytes that each player has to send out and that each player has to receive = 30 bytes. multiply by 30 players, and its 900 bytes. and I need to process each player ideally in under 200ms. Do the rest of the math and you'll see why I need at least 38400 bps

Member

also, is 220uF electrolytic plus 0.1uF ceramic too small of capacitor values because maybe with the high speed, the voltage to the module (3V) the decoupling capacitor is steadily holding on to has no more voltage left causing the unit to not work until the capacitor is charged up again? I'm not sure. The capacitor is new and has not blown up.

Or could it be that electrolytic capacitors are no-good for this module?

Member

This got weirder. I replaced two 100nF ceramics that decoupled the main 5V supply with two 100uF electrolytics because maybe that would supply the juice needed to the 3V regulator thats powering the radio module. Sadly, the data results are substantially worse (no valid data transmitted just from changing values of two decoupling caps)

Member

One more thing I can do soon is replace the standard inverter IC that the data feeds through (each data line goes through two 74HCT04 inverters) and I'll replace it with schmitt triggers (74HCT14) because I heard those clean up dirty signals and I'm trying to figure out if the change in capacitance is creating dirtier signals. hmm...

Well-Known Member

The datasheets for all low dropout regulators I have seen say that the output capacitor type and value are critical and must be mounted at the regulator IC to prevent oscillation. For the LM1117 it shows 10uF tantalum input and output capacitors but yours are completely different. If the 5V input to the regulator sags below 3.7V then the 3.3V output will also drop. If the regulator gets too hot then it will reduce the output voltage. If the load on the regulator is less than 5mA then the output voltage of some LM1117 regulators will rise.

New Member

RF chips usually need 0.01uF at vcc. Vregs need the same, close to IC. Your bit rate for the entire scene is 247k (from your numbers) and ~50uS to receive. Leaves a lot of processing time. You can also pack sender/reciever ids in a single byte. Possibly data also.