Dynex blues

[PorkRhombus]

Just getting back to Dynex again ( the subject of this thread), in my worldcodes.c, I see that code_na134Times is commented out but code_na134Code is not. Just wondering how this case is handled ( is it in fact handled properly?). I understand that it is commented because it's a duplicate of 113, but where do we tell it to use the timing table for na113 instead?

Also, a shorter hack that is equivalent to Stephanie's is to remove the hash symbol from line 10 of the makefile ( i.e. make it say NA_CODE = 1)

Just to clarify, when we talk about changing the order of transmission, are we talking about editing the very last section of worldcodes.c (the listing)?

Finally, what have all these flags to do with the US/EU pullup resistor? It seems like the US/EU selection is as much a matter of software settings as it is about the pullup resistor.

[Stephanie]

I tried typing out a detailed reply but apparently the letter N followed by the letter A is a "banned spam word" and it wouldn't let me post my reply.

On the one hand i'm curious to know what an N followed by an A might mean. Is it a bad word?

On the other hand I'm miffed that my detailed post wouldn't go through.

Sort version - yes the last section of worldcodes.c determines the order that codes are sent. The pullup resistor is only useful if you flash the chip with both regions selected -- but then you lose about 30 or 50 unpopular codes.

If you only flash one region or the other the pullup resistor is not really necessary, and you get all the codes, but for only one region.

p.s. this is not a banned spam word: nananana

[adafruit_support_rick]

At a guess, it probably got picked up from of some of the Polish spam we get here.

Somebody tried recently to post a link to a Massachusetts Institute of Technology page, which, of course, contained the popular acronym of the school. It was banned as spam. Since that's a common word in German, I'm thinking the filter picked it up from some German spam.

[PorkRhombus]

I am interested in your detailed reply, if you can bring yourself to resubmit it.

[Stephanie]

I am interested in your detailed reply, if you can bring yourself to resubmit it.

It was just a wordier way of saying what I said in the 'short version'.

Basically those last two arrays defined in the worldcodes.c - where it's just a listing of 130ish codes - is what determines the order that the codes are sent out. The north-american and european lists are separate so you can choose different orders by region, targetting the most-popular models based on locale.

It's convienent as you don't have to search through 8000+ lines of code for the actual timing arrays to change the send order, just revise those two listings.

And the pullup resistor is only useful if you have flashed the chip to contain both regions, but the tradeoff is you lose the less-popular codes due to space constraints. So if you're only using the device in north america, or only using it in europe, you're better off flashing the chip for a single region and getting all the applicable codes. In which case the pullup resistor is not really needed.

I do think it's good from a kit-making point of view of course, so a single kit can work out-of-the-box for most people in most places.

Cheers!

[PorkRhombus]

What about the fact that half the data for na134 is commented out? Where is the program directed to replace that with the na113 data?

[PorkRhombus]

Another question: The makefile uses a parameter NA_CODE which is either defined (on line 10) or not. WORLDcodes.c references a parameter NA_CODES which is, so far as I can see, not defined anywhere. Is this deliberate or a mistake ?

Please chip in if you know the answer to this or my previous question ....

[Stephanie]

I'm not seeing half the data commented out for na134 in my copy of the worldcodes file. Here's what I have, from line 4162 to 4204:

Code: Select all

/* Duplicate timing table, same as na113 !
const uint16_t code_na134Times[] PROGMEM = {
   56, 54,
   56, 166,
   56, 3945,
   896, 442,
   896, 443,
};
*/
const struct IrCode code_na134Code PROGMEM = {
   freq_to_timerval(40000),
   68,      // # of pairs
   3,      // # of bits per index
   code_na113Times, 
   {
      0x60,
      0x90,
      0x00,
      0x24,
      0x10,
      0x00,
      0x04,
      0x92,
      0x00,
      0x00,
      0x00,
      0x49,
      0x2A,
      0x02,
      0x40,
      0x00,
      0x90,
      0x40,
      0x00,
      0x12,
      0x48,
      0x00,
      0x00,
      0x01,
      0x24,
      0x80,
   }
};

It looks to me like the 4th element in the na134code array is the na113times array.

I've messed with my Makefile and didn't keep a backup, but I seem to remember, there used to be something in it that basically said if neither NA_CODES or EU_CODES were defined then define both? Oh haha it's in this thread, apparently lines 49 through 55 of the makefile.

[PorkRhombus]

OK ... I see where the duplicate data's replacement is made. Thanks for pointing that out.

My tiny mind has finally unravelled the relationship between NA_CODE and NA_CODES & EU_CODES. I see how the plural versions are defined in the makefile depending on whether NA_CODE is defined at the top of the mf. Clever.

I'm learning a lot about conditional compilation today, so I'm happy about that!

To Summarize:

1. The program makes perfect sense, it just took me a while to understand it.
2. I am going to uncomment line 10 of the makefile in order to ensure I get all the US codes and the base set of EU, rather than the base set of both codes.
3. I am going to move some of the codes, including DYNEX (134) up the playlist. Also LG if I can identify it.
4. I am going to reduce the delay between codes (line 338 of main.c) as an experiment. From 250 to 50ms.
5. I am going to recompile and verify that DYNEX shuts off, and LG shuts off faster, and the whole sequence takes less time.

Is there a listing of manufacturer vs. TV-b-gone code #'s ?