Homemade Microcontroller

Lonewolf · Post by **Lonewolf** » Thu Nov 27, 2008 5:39 am

1. Device: Microcontroller
2. Type of device: Other
3. Year: 1995
4. JP1/UEI Remote model: RS 15-133
5. Do you have a JP1 cable? Building it now
6. Still have original remote? Yes
7. Checked the file section? Yes
8. Checked Pronto file section (at R/C)? No
9. Partially working setup code? N/A
10. Learning remote question? ??

Here's one for you: I have a device that basically has a IR receiver hooked right up to the serial UART of the uC, and I need a remote to send fixed commands to it. It uses 9 data bits plus one start bit and 2 stop bits for a total word length of 12 bits, and it transmits at 1515 baud. As it is just serial data, a 0 is a 659.73 uS burst of carrier and a 1 is 659.73 uS of nothing. Most of the command are 5 words long, but a couple of them are 16 words long.

I'm thinking of 2 possible methods of transmitting the messages: 1) define 2 protocols, one 60 bits long and one 192 bits long or 2) define 1 protocol that is 4 bits long with 16 fake keys (0x0 - 0xF) and use macros to assemble the message. Option 2 might not work due to macro delay though; I'm not sure how quick it'll execute. A variant of #2 may also be possible with either a 12 or 24 bit protocol as a small gap between words is not as critical, but this will probably require quite a few more keys to be defined.

Any ideas or codes I could try?

Thanks!

/LW

Post by **The Robman** » Thu Nov 27, 2008 8:10 am

I think there are too many variables here for me to try putting together an executor for you then have you test it, I really think you need to put it together yourself.

To do this, you will need the Protocol Builder spreadsheet. Here's a help file that explains how to use it.

Use this tool to build a new protocol executor then use the "Manual Settings" mode in KM to create a corresponding upgrade.

If you need help along the way, post back here.

Lonewolf · Post by **Lonewolf** » Thu Nov 27, 2008 3:19 pm

I tried last night, but OpenOffice rejected the VBA code in PB. Unfortunately there is not a copy of Office or even Windows in this building. I'll see if I can hunt down a 'doze box somewhere I can rdesktop into.

/LW

Post by **The Robman** » Fri Nov 28, 2008 9:37 pm

What is the carrier frequency? Also, please list the data that needs to be sent (ie, the 5-word and 16-word data streams).

Lonewolf · Post by **Lonewolf** » Sat Nov 29, 2008 8:22 am

The carrier is 38kHz. As there are going to be a few codes needed, I'm hoping I can build those myself once I get a protocol built. Here are 3 of each, they should be transmitted LSB first:

start-u-u-1-5:
0xDFE 0xC70 0xCFE 0xD14 0xECE 0xEA6 0xE00 0xE1E 0xE1E 0xE8E 0xF30 0xE00 0xE58 0xE02 0xE02 0xF50

start-10-u-2.5-5:
0xDFE 0xC70 0xCFE 0xD14 0xECE 0xEA6 0xE00 0xE0C 0xE1E 0xE8E 0xF30 0xFC0 0xE58 0xE02 0xE00 0xE46

download:
0xDFE 0xC60 0xCFE 0xD14 0xEF6 0xE00 0xE00 0xE00 0xE00 0xE00 0xE00 0xE00 0xE00 0xE00 0xE00 0xFDA

yellow:
0xDFE 0xC10 0xCFE 0xD00 0xEC8

red:
0xDFE 0xC10 0xCFE 0xD0A 0xFA6

ack:
0xDFE 0xC30 0xCFE 0xD50 0xEAA

In other news, I have IR running under wine, RM is working, and my JP1 cable works just fine

I did manage to get a copy of Excel 2002 installed, but it rejects everything I put into the Protocol ID cell and the protocol code box is filled with "#NAME?"

/LW

Post by **The Robman** » Sat Nov 29, 2008 11:08 am

The reason I need to see all of the hex codes is because I need to see which bytes are variable and which are not. If I make every byte variable, the upgrade would have 16 bytes per button and it would be HUGE.

If you have Excel installed, make sure you have the VBA addin installed.

Lonewolf · Post by **Lonewolf** » Sat Nov 29, 2008 11:34 am

The fist byte will always be 0xDFE; all the others are variable. I was planning on making 2 protocols, 1 with 16 bytes and 1 with 5 to help keep the size down.

I don't know what's wrong with Excel. All the other fields validate correctly, it's just the Protocol ID that's not getting accepted. I'll check the VBA add-in.

/LW

Ok, I did some searching here and got PB working, w00t! Now if only there was a way to tell it to prepend one 0 and append two 1's to every byte to reduce the size a bit... Actually, if I could code some math in to make it generate the 9th bit, that would reduce the byte size back to 8 bits. I guess it's time to dig up the datasheet and learn the assembly for this uC...

Edit: It looks like both RM and KM can only handle 8-bit commands. Grrrr. Time to get creative >.<

/LW

Lonewolf · Post by **Lonewolf** » Tue Dec 09, 2008 6:15 pm

Well, I've got it mostly working. Because of the size, I had to break it up into 4 different buttons and then join them back together with a macro. However, this is only working for non-shifted buttons; if I try to program something onto a shifted/xshifted button, I get gibberish. I'm using 6 8-bit bytes per button.

Code: Select all

Upgrade Code2 = 00 00 (Cable/0000) (RM v1.86)
 01 10 00 81 7F B0 E3 BF 9C A2 73 7B 2B 80 3D E1
 78 7B 8B 86 7C 01 1A 7A 03 80 3C 97 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
KeyMoves
 9F F0 08 00 00 7F B0 E3 BF 9C A2«0: gsbs - part 1»¦
 95 F0 08 00 00 73 7B 2B 80 3D E1«1: part 2»¦
 96 F0 08 00 00 78 7B 8B 86 7C 01«2: part 3»¦
 97 F0 08 00 00 1A 7A 03 80 3C 97«3: part 4»
End

With the above upgrade, buttons 0-3 are working wonderfully while SHIFT(0)-SHIFT(3) are failing miserably

I've tried both the stock non-extended firmware and both extenders.

/LW

Post by **The Robman** » Tue Dec 09, 2008 8:34 pm

The upgrade is meaningless without the protocol portion.

In unextended remotes, the SET button needs to be pressed twice to activate shifted numeric buttons. Have you tried using any keys other than the numeric keys for this experiment?

Lonewolf · Post by **Lonewolf** » Tue Dec 09, 2008 9:21 pm

I'm calling it in a macro, but yes, while testing individual buttons I was hitting "P" twice. I've also tried with the Guide, Menu, Info, and phantom1 buttons with the same result; some of the gibberish changes depending on which button it's assigned to, some stays the same, and I do get a few 'good' bits every now and then.

Protocol:

Code: Select all

Upgrade protocol 0 = 01 10 (S3C8+) v4 start alpha3 (PB v4.00)
 31 9E 06 8B 14 8C 10 00 08 00 01 01 2C 01 3B 00 
 01 00 00 FF FF FF FF FF 01 8D 01 46 
End

/LW

Lonewolf · Post by **Lonewolf** » Wed Dec 17, 2008 5:46 am

Ok, now I'm getting somewhere: it seems Key Moves have a limit of 16 bits; only 'normal' keys can be 64 bits. Grrrr. Oh well, workaround implemented, macros functioning correctly. Now, if I could just get it to repeat the ENTIRE macro when you hold a button down it would be PERFECT! That and make the backlight stay on just a little longer...

/LW

Post by **The Robman** » Wed Dec 17, 2008 10:12 am

Could you post the KM and PB files that you're using, as I might be able to offer some tips.

Lonewolf · Post by **Lonewolf** » Wed Dec 17, 2008 5:45 pm

So I go to put together a KM file for you as I have been using RM, and it turns our KM will not let you use Key Moves if the protocol is longer then 2 bytes (that whole sheet is grayed out). I'm not sure if I should call this a bug in RM or a lack of documentation... Do you still want to see the RM and PB files?

/LW

Post by **The Robman** » Wed Dec 17, 2008 9:16 pm

Sorry, I should have said KM or RM file, I didn't mean to imply that I only wanted to see a KM file.

Lonewolf · Post by **Lonewolf** » Wed Dec 17, 2008 10:29 pm

Zip file. Left and right arrows work as expected; shifted they do not.

broken_long_code-pb.txt - PB save file
broken_long_code-protocol.txt - PB output
broken_long_code.rmdu - RM save file
broken_long_code-upgrade.txt - RM output

/LW