Trouble setting up an old Blaupunkt remote

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Thomas Orgis
Am Sun, 12 Feb 2017 22:20:48 +0100
schrieb Bengt Martensson <[hidden email]>:

> Since you have a really cool IR analyzer in the pipeline, lets wait
> until you have that. In conjunction with IrScrutinizer, you will see
> that its signal analyzing capacities blows Lirc away...

Well, then … I built your transceiver with my Arduino Nano clone. It
worked right away and I attached the captured remote config exported
from IrScrutinizer. As we already knew, the remote sends very short
sequences that make it tricky also for the scrutinizer to deduce the
properties. The detected frequency varies between 34 kHz and 38 kHz.
The big win is that your program is indeed able to generate a config
that makes lirc recognize individual buttons, but with varying success
rate.

Using the Irdroid, different buttons can be detected, but there is a
number of buttons that cannot be told apart / detected at all.

Using the girs driver with the new transceiver, trying the second
config generated with more care, all buttons are detected correctly.

What do you think about the frequency? 30 kHz seems unlikely to me now.
I am still leaning towards 38 kHz … But something like 34 or 36 kHz might
work, too. Perhaps that is a reason for the TOSP34438 working better
than the TSOP4838; the latter ignoring more of the signal at the fringe
of the accepted frequency range. I actually ordered receivers with some
differing frequencies to test later.

Or … could it be that the remote just doesn't have a stable frequency
with its aged components?

Hah! I knew it was a good idea to order two TOSP34438 right away: After
replacing stock sensor on the Irdroid (4838? no markins on these …), it
also detects the remote just fine. The TOSP34438 is clearly more
tolerant.

While the new transceiver worked splendidly for recording and
detectiong the remote, I have mixed results when trying to send
something. Rarely, it seems to work (so far did not check if really a
signal came out), but almost exclusively I get this:

lircd-0.9.4d[2633]: Info: girs: transmit module found
lircd-0.9.4d[2633]: Info: girs: receive module found
lircd-0.9.4d[2633]: Info: girr: Found version "GirsLite 2015-12-01"
lircd-0.9.4d[2633]: Error: error processing command: SEND_ONCE ledlicht1 power
lircd-0.9.4d[2633]: Error: transmission failed
lircd-0.9.4d[2633]: Info: removed client

Same with current git version. I wondered if I might have done
something wrong with the soldering, but transmitting signals in
IrScrutinizer works like a charm. So it is just the lirc driver that is
not ready yet. Sorry if I forgot that you told me about that already.

Well, all in all … With the config from IrScrutinizer and using the
TSOP34438, the remote works now. For the heck of it, I will try
irrecord with the newly modified Irdroid. That doesn't fly:

Now hold down button "power".
Something went wrong: Cannot decode data
Please try again. (13 retries left)

Well, I got another way to get configs now … at least for such an
ancient remote. Thanks for your support!


Alrighty then,

Thomas


PS: I was not able to simply kill lircd -H girs on occasion… pkill -9
did the trick, finally. It got stuck somehow … but until then it worked
fine. Not sure if the device locked up.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

lirc_2017-02-17_00-54-36.lircd.conf (2K) Download Attachment
attachment1 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Bengt Martensson-2
On 02/17/17 01:49, Thomas Orgis wrote:

> Am Sun, 12 Feb 2017 22:20:48 +0100
> schrieb Bengt Martensson <[hidden email]>:
>
>> Since you have a really cool IR analyzer in the pipeline, lets wait
>> until you have that. In conjunction with IrScrutinizer, you will see
>> that its signal analyzing capacities blows Lirc away...
>
> Well, then … I built your transceiver with my Arduino Nano clone. It
> worked right away and I attached the captured remote config exported
> from IrScrutinizer. As we already knew, the remote sends very short
> sequences

Did "we"? ;-)

> that make it tricky also for the scrutinizer to deduce the
> properties. The detected frequency varies between 34 kHz and 38 kHz.

Your captured signals do not look very good at all. Normally the
frequency is determined quite reliably, i.e. does not vary between
measurements. My advice is to try to (as a test) capture a known remote,
e.g. RC5, NEC, or Sony. Does that give you reliable and reproducible
measurements?

And please use the current AGirs firmware.

...

> While the new transceiver worked splendidly for recording and
> detectiong the remote, I have mixed results when trying to send
> something. Rarely, it seems to work (so far did not check if really a
> signal came out), but almost exclusively I get this:
>
> lircd-0.9.4d[2633]: Info: girs: transmit module found
> lircd-0.9.4d[2633]: Info: girs: receive module found
> lircd-0.9.4d[2633]: Info: girr: Found version "GirsLite 2015-12-01"
> lircd-0.9.4d[2633]: Error: error processing command: SEND_ONCE ledlicht1 power
> lircd-0.9.4d[2633]: Error: transmission failed
> lircd-0.9.4d[2633]: Info: removed client
>
> Same with current git version. I wondered if I might have done
> something wrong with the soldering, but transmitting signals in
> IrScrutinizer works like a charm. So it is just the lirc driver that is
> not ready yet. Sorry if I forgot that you told me about that already.

Try the current version of the firmware. Then you have to turn on more
debugging (--loglevel). What is the version of the driver?

...

> PS: I was not able to simply kill lircd -H girs on occasion… pkill -9
> did the trick, finally. It got stuck somehow … but until then it worked
> fine. Not sure if the device locked up.

Try this: After sending the signal with kill, shoot an arbitrary IR
signal at the receiver. Lircd might be waiting for "something" and
refuses to quit before it gets "something". Just waiting for the timeout
(around 10 seconds) might also do the trick.

Greetz,

Bengt

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Thomas Orgis
Quick reply before I run …

Am Fri, 17 Feb 2017 09:31:52 +0100
schrieb Bengt Martensson <[hidden email]>:

> > properties. The detected frequency varies between 34 kHz and 38 kHz.  
>
> Your captured signals do not look very good at all. Normally the
> frequency is determined quite reliably, i.e. does not vary between
> measurements.

It does look much more stable around 38 kHz (some variation is
expected, isn't it?) with one of the normal remotes, but those really
send much longer sequences so I'd expect that the result is more
reliable with more data.

> My advice is to try to (as a test) capture a known remote,
> e.g. RC5, NEC, or Sony. Does that give you reliable and reproducible
> measurements?
>
> And please use the current AGirs firmware.

Will do … I just followed your guide, which mentions the one I used
only and was happy that it worked at all. I'll check for an update in
the evening.

> Try the current version of the firmware. Then you have to turn on
> more debugging (--loglevel). What is the version of the driver?

This is lirc cloned from git. I'd expect this to be the most current
one?


Alrighty then,

Thomas

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Thomas Orgis
Am Fri, 17 Feb 2017 10:03:46 +0100
schrieb Thomas Orgis <[hidden email]>:

> > And please use the current AGirs firmware.  

Got it now and this fixes sending in lirc. Irrecord is still without
hope trying to make sense out of this remote, but using the config from
IrScrutinizer, things work nicely, with normal lirc-0.9.4d.

Thanks for your work on this!


Alrighty then,

Thomas

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Thomas Orgis
In reply to this post by Thomas Orgis
Am Mon, 13 Feb 2017 01:26:12 +0100
schrieb Thomas Orgis <[hidden email]>:

> analyzer draws? I wonder how good my chances are to run two of them off
> the single USB port of the Beaglebone with a passive hub …

I should have realised early on that this is a rather stupid/lazy idea.
I should just connect receiver / transmitter parts to the beagle bone
itself and use

        https://github.com/hani93/lirc_bbb

for driving them via GPIO. The beagle bone has two microcontrollers on
and lots of IO pins board already … it's rather redundant to attach
another µC. I previously was not aware of someone having bothered
writing (adapting) the kernel driver for that yet.

Well, if I have some time to burn (*cough*), I can do this properly,
until then the USB transceiver will work, of course.


Alrighty then,

Thomas

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Bengt Martensson-2
In reply to this post by Thomas Orgis
On 02/17/17 21:05, Thomas Orgis wrote:
> Am Fri, 17 Feb 2017 10:03:46 +0100
> schrieb Thomas Orgis <[hidden email]>:
>
>>> And please use the current AGirs firmware.
>
> Got it now and this fixes sending in lirc. Irrecord is still without
> hope trying to make sense out of this remote,

IMHO, we do not need irrecord :-).

> but using the config from
> IrScrutinizer, things work nicely, with normal lirc-0.9.4d.

Nice to hear.

> Thanks for your work on this!

Hmm, your way of "paying back" is to report how the different issues
were solved. This mailing list is not a support hotline. In particular,
I would like to know what the irsignals sent by your remote really look
like: your file contained samples of widely differing length, with a
large number of different values (normally there are only a few, of
course with measurement errors). And the frequency...? Did my
explanation/fix to lircd-not-quitting-from-kill fit? Etc.

Greetz,

Bengt

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Bengt Martensson-2
In reply to this post by Thomas Orgis
On 02/18/17 11:08, Thomas Orgis wrote:
> Am Mon, 13 Feb 2017 01:26:12 +0100
> schrieb Thomas Orgis <[hidden email]>:
>
>> analyzer draws? I wonder how good my chances are to run two of them off
>> the single USB port of the Beaglebone with a passive hub …
>
> I should have realised early on that this is a rather stupid/lazy idea.

Even worse, really, to have USB emulating the RS232 protocol (from
1969!). Alternatives are, e.g. the serial ports directly on the GPIO
pins, or possibly I2C.

> I should just connect receiver / transmitter parts to the beagle bone
> itself and use
>
> https://github.com/hani93/lirc_bbb
>
> for driving them via GPIO. The beagle bone has two microcontrollers on
> and lots of IO pins board already … it's rather redundant to attach
> another µC.

I am not sure if I agree about this. If you are generating the carrier
in software, you have (for typical 38kHz frequency) 2*38000 interrupts
per second, which is not really what multitasking OS shines at. Using
hardware PWM reduces this a bit (see post by [hidden email]
earlier this month), but still a few thousands interrupt per second. A
co-processor may not be a bad idea -- definitely not "redundant"!

> I previously was not aware of someone having bothered
> writing (adapting) the kernel driver for that yet.

While on it, consider https://github.com/bengtmartensson/lirc_rpi
and
https://github.com/Al-/lirc_rpi_hardpwm.

Greetz,

Bengt

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Thomas Orgis
In reply to this post by Bengt Martensson-2
Am Sun, 19 Feb 2017 10:32:32 +0100
schrieb Bengt Martensson <[hidden email]>:

> IMHO, we do not need irrecord :-).

Well, a command-line version of the “scrutinize remote” tab, with the
better logic but without all the GUI/JVM around it, would be a true
replacement. Sometimes you do not need/want the whole workshop but
just a multimeter in the bag. And as long as a tool named irrecord is
shipped with lirc, people will assume it is the tool to use to record
IR signals …

> I would like to know what the irsignals sent by your remote really look
> like: your file contained samples of widely differing length, with a
> large number of different values (normally there are only a few, of
> course with measurement errors). And the frequency...?

The signals do look like that. Differing lengths seem to be real.
I now analysed some buttons in detail, pressing them for at least
around a dozen repeats to help IrScrutinizer derive singal properties.

Once I press the button long enough, the frequency seems to be stable.
Occasionally, there could be a slightly differing value, but I suppose
that is just the next quantisation step for the “real” frequency being
close.

power: 34482 Hz

+360 -360 +544 -1054 +544 -709 +544 -65535
+361 -361 +544 -1055 +544 -709 +544 -65535
+361 -361 +543 -1056 +543 -709 +543 -65535
+361 -361 +543 -1055 +543 -709 +543 -65535
+361 -361 +544 -1055 +544 -709 +544 -65535
+361 -361 +544 -1055 +544 -709 +544 -65535

mute: 34482 Hz

+358 -1401 +1104 -709 +544 -65535
+359 -1401 +1104 -709 +544 -65535
+358 -1401 +1104 -709 +543 -65535
+358 -1401 +1104 -709 +544 -65535

5: 36363 Hz

+1693 -334 +608 -608 +608 -65535
+1693 -334 +608 -608 +608 -65535
+1694 -334 +608 -608 +608 -65535

vol+: 34482

+358 -705 +547 -705 +547 -705 +547 -65535
+358 -703 +549 -703 +549 -703 +549 -65535

Differing lengths. Differing frequencies.

So, let's summarise the frequencies. I have a second one of these
remotes on the way (for the heck of it … after I spent time/money on
equipment being able to make sense out of these) and am curious to find
out if it has the same variation in frequency or if this is a quirk of
a hardware defect of this one.

mute 34482 Hz
aux 37037 Hz
me 37037 Hz
power 34482 Hz
1o 35714 Hz
1 36363 Hz
2 35714 Hz
3 37037 Hz
2o 37037 Hz
4 34482 Hz
5 36363 Hz
6 35714 Hz
3o 34482 Hz
7 37037 Hz
8 34482 Hz
9 36363 Hz
bright- 37037 Hz
bright+ 35714 Hz
0 34482 Hz
n 34482 Hz
col- 35714 Hz
col+ 34482 Hz
vol- 35714 Hz
vol+ 34482 Hz
tre- 37037 Hz
tre+ 35714 Hz
bass- 36363 Hz
bass+ 34482 Hz
bal_l 37037 Hz
bal_r 35714 Hz
pause 35714 Hz
roll 36363 Hz

So we got these freqs:

A: 34482 Hz
B: 35714 Hz
C: 36363 Hz
D: 37037 Hz

The layout of frequencies on the remote is like that:

A D D A
[empty row]
B C B D
D A C B
A D A C
D B A A
B A B A
D B
C A
D B
B C

You see a pattern? It looks like something diagonal is going on … well,
I am having a look at the inner parts of this thing. See

        https://thomas.orgis.org/div/blaupunkt_8668812302_kontakte.jpg

for the contact board (two more buttons are prepared in the empty row
but not present on the outside) and

        https://thomas.orgis.org/div/blaupunkt_8668812302_innereien.jpg

for the electrical parts.

The obsured traces on the layout don't help, but some links are
apparent. Since there are 34 buttons prepared, I'd expect something
like a 6 x 6 matrix. The number of pins used for the buttons seems to
be 13 … so maybe 6 × 7. Thinking again, since one physical row has 4
buttons and we got 4 distinct frequencies, a 4 × 9 matrix would also
fit the bill. Then all buttons sharing a virtual row/column would share
that frequency. But this does not really explain why there are
differing frequencies to begin with.

Maybe a capacitor value is off, turning the circuit unstable, and a
combination with trace lengths / differing resistances results in
differing frequencies. Is something like that known to happen?

If I do not try to fix the remote (assuming it has a fault), using a 36
kHz receiver looks like a reasonable fit, but the tolerance of the
TSOP34438 seems fine for this spread.

> Did my
> explanation/fix to lircd-not-quitting-from-kill fit? Etc.

It might, but this did not occur with the latest firmware yet, so I
just assumed that this was a glitch that is solved already. Ten seconds
delay could fit for the occurence I had with the old firmware. I will
keep in mind the trick with sending some signal to shake things up.


Alrighty then,

Thomas


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Thomas Orgis
I got a second remote of the same type now and can compare. The button
codes seem equal as all buttons are recognised with my existing lirc
config. I am looking at the frequencies now.

Am Sun, 19 Feb 2017 14:46:18 +0100
schrieb Thomas Orgis <[hidden email]>:

> So we got these freqs:
>
> A: 34482 Hz
> B: 35714 Hz
> C: 36363 Hz
> D: 37037 Hz
>
> The layout of frequencies on the remote is like that:
>
> A D D A
> [empty row]
> B C B D
> D A C B
> A D A C
> D B A A
> B A B A
> D B
> C A
> D B
> B C
Now the new remote …

A D D A
[empty row]
B C B D
D A C B
A D A B ??? A D A C ?? B D A B ?? A D A B
D B A A
C A C B ??? B A B A ?? C B C B
D B
C A
D B
B C

It mostly seems to agree, but there are two rows that seem to give
inconsistent signals. I have the suspicion that this relates to the
time the remote had since the last keypress. This particular device
clearly has a power supply capacitor past its prime (in the
process of distributing itself throughout the device).

I replaced that capacitor and now the frequencies do seem more
consistent. The fourth populated row still reads A D A B instead of A D
A C, but that may be an inconsistency for the first remote (got to
replace the capacitor there, too).

In any case: I got two remotes now that seem to agree on a certain
pattern of modulation frequencies depending on button location. Did you
see anything like that before? Could this be by design / a design flaw
getting apparent with age?


Alrighty then,

Thomas

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Trouble setting up an old Blaupunkt remote

Bengt Martensson-2
On 02/21/17 23:16, Thomas Orgis wrote:
> I got a second remote of the same type now and can compare. The button
> codes seem equal as all buttons are recognised with my existing lirc
> config. I am looking at the frequencies now.
>
...

>
> It mostly seems to agree, but there are two rows that seem to give
> inconsistent signals. I have the suspicion that this relates to the
> time the remote had since the last keypress. This particular device
> clearly has a power supply capacitor past its prime (in the
> process of distributing itself throughout the device).
>
> I replaced that capacitor and now the frequencies do seem more
> consistent. The fourth populated row still reads A D A B instead of A D
> A C, but that may be an inconsistency for the first remote (got to
> replace the capacitor there, too).
>
> In any case: I got two remotes now that seem to agree on a certain
> pattern of modulation frequencies depending on button location. Did you
> see anything like that before? Could this be by design / a design flaw
> getting apparent with age?

I sent a pointer to this thread to the protocol experts at JP1:
http://www.hifi-remote.com/forums/viewtopic.php?t=100440 but there has
been no answer.

My suspicion is that the remote is older than the current concept of an
IR remote: a fairly well defined carrier frequency that is being
filtered through a fairly steep band-pass filter like a modern TSOP***.
(Now "we" can make fairly stable oscillators even without resorting to
crystals.) The fact that the measured frequency varied with the change
of an elko (!!) supports that theory. So it appears not to be a very
good choice of a remote to build upon (repeating myself).

I suspect that the individual pulse are also quite different from one
another, not a sequence of equidistant pulses.

Greetz,

Bengt

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
12