davidgriffith / bluebox-avr Goto Github PK

It might be a good idea to implement some sort of wear-leveling scheme to keep the EEPROM from dying early. It was suggested to me that some sort of round-robin scheme would do.

Doodles...

struct chunk {
    uint8_t generation;
    uint8_t id;
    uint8_t mode;
    uint8_t speed;
    uint8_t data [32];
    uint8_t checksum;
}
struct chunk[12] eeprom;

id ranges from 0-12 with 0 being the startup mode (data part ignored). On startup, scan the eeprom for chunks with correct checksum and highest generation number.

When writing, increment the generation number and write after the last valid chunk and start from the beginning when reaching the end.

If the power is switched on and off rapidly, the contents of the EEPROM will often get corrupted. Instead of playing the startup beep of 440 Hz, a buzz is heard and no keystrokes will do anything. Remove power and apply it again, now I get a beep code indicating that the tone length setting is corrupt. This corresponds to eeprom[2]. Occasionally some other location gets corrupted.

It seems wasteful to use 8 bits per key when 4 would be adequate. I got lazy early on.

In the hardware, the 2600 key appears above the 2 key. However, when I wired up the prototype on perfboard, I put the 2600 key after the hash key in the resistor ladder. That was an accident. I should have placed the 2600 key at the top of the resistor ladder. However, I'm stuck with the configuration in getkey() while I'm still using the prototype. Once I fix the problems with tones not being recognized, I should be able to make some PCBs and retire the prototype.

When the startup mode is set by holding 2600 on power-up and selecting the desired mode, that is supposed to be saved in EEPROM. If I turn off the unit and back on, it sticks. But if I let the unit sit without power for a couple minutes, the setting is lost.

The quality of the DTMF tones is a bit troublesome. I used multimon (https://sourceforge.net/projects/multimon) sampling from my laptop's build in microphone to check the tones. When a tone is played once, it is often detected twice or thrice. This doesn't happen if I play tones from a Radio Shack #43-139 pocket dialer. The problems happen more often with 7, 8, 9, *, 0, and #.

I tried an Android DTMF decoder app called "DTMF Decoder". They all stink to varying degrees. This had problems decoding digits from the third column. Again, no problems with the Radio Shack pocket dialer.

I need to get this thing on an oscilloscope to get a better idea of what's going on.

Possible culprits:

1. The low-pass filter after the output pin is inadequate, perhaps wrong corner frequency.
2. 7-bit resolution isn't good enough. 8-bit should then be good enough. Then I'd have to output on two pins and mix on the board.