Decoding and replicating IR signal (part 2)

I seem to have completely forgotten this post, it's been draft for more than a year now. Sorry about that

Part 1 here .

First, why didn't I use dedicated IRDA peripheral on chip? Because I had absolutely no idea of the parameters involved, have never used it - and most importantly, it would have been really difficult to wire on my board since existing design didn't have correct IO exposed. And I really just needed to have few select messages to send, so copying signal timing was good enough. 

Over time I pondered on my spare time how I could make receiver better, less sensitive to signal timing. Previous attempt used IO interrupts,which caused system to occasionally miss one due to timings, so that was no go. Eventually I got a rouch draft of an idea working;

- Set up a timer peripheral to run at twice or clock rate of IR signal (this I could measure with scope, 76 kHz in this case as I wanted both "up" and "down" parts; actual modulation was running at 38 kHz). As listened this does nothing but increase a counter on every tick. This makes period of 13us per tick.

- All other interrupts are disabled

- Main loop does nothing but polls IO input line and on change, it first takes counter increased by timer above and stores its value (Tcurr).

- Now we take timer difference from last change (Td = Tcurr-Tlast). If the value is less than 3, this is modulation and we can ignore it; this is stored as "last activity" count (Tlast = Tcurr). Very first change triggers storing TmodLast.

If difference between from previous "last activity" (Tlast) count is larger (more than 200uS or so), we know that this was "modulation off" period which actually carries bits; now next modulation period was started.

Now compare difference from previous Tlast and TmodLast to get previous "modulation on" length. First is preamble (3600us or so) which resets receiver. All shorter (400us) periods were here for timing; more sophisticated system might use them for data too.

For this sequence, I treated 400us "modulation off" period as "0" and 1200us period as "1". 

- After longer off period, system automatically ends receiving.

This above is the end result, original idea had some flaws I found out when writing the code (debugging it was a bit difficult due to very strict timing requirements! Lot of debugging in the end was done by triggering few IO lines and monitoring IR data and said lines on oscilloscope that those happened when expected). In the end I had receiver working. 

Appendix on 2024: I later had to re-record signals as device I was controlling changed, and this time I got lazy. I just demodulate signal (using commercial demodulating receiver) and store on-off periods, without bothering to actually decode it. 

Replay is done with timer interrupt by toggling IR LED state when signal is "on"; main replay function merely keeps track on state and timing, and sets "IR modulating" signal for interrupt. Much simpler, but at same time far less satisfying...

Cheapest IR controller ever

As usual, I haven't really had anything interesting to write so once again apologies for my extended breaks from posting. Unfortunately I don't see this changing anytime soon.

That being said, today I found this IR remote controller that re-defines what "cheap IR controller" actually means.

This came with (also extremely cheap) LED toy, and is used to toggle it on or off. And of course it broke immediately, after being thrown. There was no real damage, just battery had fallen off, but nevertheless.

There is nothing on the other side of the board. IR LED pins are under the board and those are pins at the bottom middle. Underneath the "cross" (battery holder, battery is not there currently) there is simple press-button dome, giving this conroller surprisingly good tactile sense (compared to usual rubber membranes); user presses down on the cross part, pressing battery against holder and button dome. No modulation, no signalling, just LED on or off.

The only component on the board is single diode seen on bottom left. There isn't even current limiting resistor anywhere! I guess they rely on internal rersistance of the battery there.

And yes, toy can be turned on and off with just about any remote controller one might have lying around. I tried few immediately when I saw what's inside this.

TIL: SQL Limit is slow

 It's been a while since I wrote anything. Mainly reason is that I have been very busy with work and other things, and consequently have had very little time to do any fun experimentation that would (or could) be noteworthy here.

Until now that I ran onto something. I have a Postgresql database with several tens of millions of rows. At one point performance got very bad so I updated to indexes, problem solved.

Now I was doing testing with new feature that does data analysis and did simple query, for testing (x.col being indexed column);

select a,b,c from table x where x.col=something and x.id=12345;

Trivial query and it did complete in milliseconds. In initial testing I wanted to just use one specific row to get started.

When things was working okay for that row, I wanted to update this so I can process things one at a time - again, to verify things work as expected;

select a,b,c from table x where x.col=something limit 1;

This query took ridiculously long time to complete, close to a minute or so. And returned zero rows.

So I did what anyone would, asked postgre to explain what it did. And it showed sequential scan. What?

Okay, when things fail, fall back to something trivial and start working back, so let's try something simpler...

select a,b,c from table x where x.col=something;
(0 rows returned)

This ran again in milliseconds. So limit did something not fun.

Time for googling, and yes, limit apparently manages to make postgre fall back to sequential scan in some cases. 

So there. Drop limit from query and process just one row (for now). And then check around in how many places exactly I am using limit needlessly...

Maybe something many already knew, but I didn't. Ah well.