RC5

[ELECTRONICA67]

TX SIGNAL; While the TX button is pressed, the signal remains high.

[ELECTRONICA67]

Out of TX PIC12F1840 RC5 This is the signal coming directly from pin A2, which then connects to the base of a 2N3904 transistor that activates the IR LED.

[mnfisher]

Hi Enrique,

It's not looking quite right yet. This is the trace I get - transmitter 12f1840 (as posted), and receiver - just connected to the signal pin. I'll connect this to a receiver today (unfortunately the 'receiver' PIC is still in transit - so an Arduino for the moment!)

I'm not 100% sure the transmission (top trace) is correct - would have to compare to Arduino version / check decoded signal...

LabNation_Screenshot75.png (235.49 KiB) Viewed 58 times

Martin

[ELECTRONICA67]

Hi Martin,

Thanks, Martin. I don't have experience with encoded signals, so I appreciate your help. Some time ago, Martin (Medelec) recommended using a logic analyzer—I’d actually forgotten I had bought one back then.

Will that help me check the signals

Enrique

[chipfryer27]

Hi

Going back to our Rx chart a few posts ago, I'm not sure I'm understanding the flow. I can only simulate not having the IR receiver, so things will be different in HW.

You briefly flash the LED as a "test" then using a C-block set B1 and B2 to be outputs. Why? These ports are associated with your display and the component will deal with this itself so I am unsure as to why you are setting them. I don't know enough about the internals of FC but you may be risking disassociating the component. Not sure about that though.

You then display "12" but have the brightness at "1" which is very low and would possibly be difficult to see. After displaying "12" you then turn off the display and set brightness to "0".

Immediately after this you try and display digits on the display, but it is at zero brightness and off.

You then enter your main loop which runs around until you receive something via your RC5.

In that branch you turn on the LED (never turning it off) then read whatever has came in. You then display this result by again setting the display to it's lowest brightness having again set ports B1 and B2 to be outputs. I really don't understand this step at all. Then 10mS later you switch off the display. My eyes may be old but I doubt many people would see anything in only 10mS let alone a dimmed 4-digit number

The points above are not your showstopper though, that would be why your LED doesn't illuminate in your loop. As it will only come on if you have received a valid incoming RC5 signal you need to start there. Why are you not receiving valid data?

Referring to your first "scope" post, showing SIG1 and SIG2 would you please clarify? What is SIG1 actually connected to and what is happening? For example connected to IR receiver with TX button pressed or whatever. Do you have access to any other RC5 transmitter on the same frequency? Perhaps a TV transmitter or the like? That would make testing easier.

The next posts of scope traces don't look too healthy which I believe are Tx traces. The voltages look way too low. Have you perhaps set your probe to 10x instead of 1x? With a vertical scale of 2v/div your trace should take up almost half your screen and be clearer to see. The timebase looks a bit slow too to capture expected bursts. It is tempting to just press "Auto" on a scope but sometime this can be confusing unless you know for sure you will be capturing a valid signal.

Heading out now but good luck in faultfinding.

Regards

[chipfryer27]

Hi

Just see you and Martin have added.

The logic analyser will be a great help.

Regards

[ELECTRONICA67]

Hi,

B1 and B2 were just parameters I used in the program's original sequence. I used the SLEEP command and made transistor-based adjustments to power down components when not in use, thereby reducing current draw for battery operation. With B3, I activate a transistor that powers the display so the value is only visible when needed, avoiding unnecessary battery drain. I use LED A2 to signal when RC5 data is detected; since I wasn't sure if the display was working, the LED serves as an indicator of data detection.
For sig1 and sig2, I measured the RX receiver output while pressing the IR remote button (using the RC5 protocol). In this test, I’m using the TSOP31236, which operates at the 36 kHz frequency required by the Flowcode RC5 component; however, I also have an 1838 receiver that operates at 38 kHz (a common model for Arduino). The goal is to use the Flowcode RC5 transmitter and receiver to encode IR-based functions—such as reading values, resetting readings, or triggering audible signals.
The final signals come from the TX transmitter (PIC12F1840 pin A2). The last two traces show the raw signal from pin A2 (where the level is very low), while the others were captured after a transistor was triggered to drive the IR LED and boost its output power. However, the interface I built between the PIC and the IR LED's driving transistor might be using the wrong transistor type (a 2N3904) given the switching speeds required by the RC5 TX component.
I found a logic analyzer I bought a while back; that might make it easier to understand the encoded communication and pinpoint the problem. As I told Martin, I don't have experience with encoded signals, so I appreciate the help.

Saludos

[chipfryer27]

Hi

Sorry to be brief, just heading out.

I think it better to start with your transmitter and then move on to your Rx once you are sure you are transmitting correctly (unless you have a known working transmitter at 36KHz such as a TV remote). My understanding is that your receiver will accept most protocols including RC5 and it looks like you are receiving "something". So lets focus on your transmitter.

Both Martins have provided excellent help within the forum(s) regarding RC5 so my suggestions are not in any way contrary to their advice.

I would start by refamiliarising yourself with your logic analyser (if needed). I know the type you have and still use one when needed. Although entry level working with open-source software, it is remarkably useful and can even decode protocols for you. It certainly punches way above its weight and being very cost effective should be in everyone's toolkit so to speak. Incidentally the Eblock is based on similar I believe, and if you use Eblocks and don't have the Eblock analyser, you should seriously consider getting one.

Perhaps start be creating an endless loop toggling a pin at whatever rate you wish. Perhaps 500mS On / Off or the like as you can check this with an LED or multimeter. Set up your logic analyser to trigger on a rising edge and capture a few cycles. Then increase your rate. Perhaps working down to 10uS On / Off. I would then alter my chart to give a "burst" of 10us signals every 20mS or so and try and capture a few bursts. This is just to familiarise yourself again with the analyser. Also set to trigger on falling edges too as you will need that when you test your chart.

Once you are happy with using it then connect directly to your microcontrollers Tx pin, appropriately triggering when a button is pushed. You should see patterns similar to what Martin published. Those traces will be a great help.

Regards