search

travisgoodspeed / goodwatch

Replacement board for Casio Calculator Watches using the CC430F6147
503 stars 55 forks source link

Unlucky Number 7 #116

Closed notpike closed 4 years ago

notpike commented 5 years ago

Hi,

I'm working on an application for the GoodWatch where it can control the TouchTunes jukebox via it's wireless interface. I know that you can add in symbol rates and signal values into the config file but my overall plan is to add features such as receiving and message encoding so it can do more then 10 commands for one PIN. I've already have a working prototype but there's one small glitch...

The problem I'm having right now is that the #7 key pad dose not want to play well when I define a Switch/Case for it (Line 178 in jukebox.c, Link below). For some odd reason when ever the loop detects it being depressed it only transmits for a brief moment then cuts off. Now when ever I change that case to, for example '.', it works just fine.

I don't believe this being a hardware issue (with the physical keypad) because when I tested this with two separate watches with the same result. Another reason I don't believe it's a physical defect is that the lcd_string() function is still gets triggered when the radio_getstate() equals 19 when the #7 is depressed. Also I've hard coded in 10 cases including the #7 key into the ook application and it worked just fine, it's just something in my code that's making a gremlin appear.

I'm new to programming in C so I'm not quite sure how to fix this. I can work around this so this isn't braking anything but I was wondering if this a known issue or not. The hardware I'm working on is the GoodWatch22. Any advice or tips would be greatly appreciated.

Thank you!

==JukeBox.c== https://github.com/notpike/goodwatch/blob/master/firmware/apps/jukebox.c

==My Fork== https://github.com/notpike/goodwatch

travisgoodspeed commented 5 years ago

Howdy @notpike!

Thanks for a well written issue! It made this nice and easy to reproduce.

In jukebox_packettx(), you only transmit if radio_getstate()==1, but sometimes the state will be 20 because the prior packet hasn't yet finished transmission. You can fix this by either not checking the radio state in jukebox_packettx() or by waiting for it to settle out of transmit mode in the beginning of your function.

while((radio_getstate()&~1)==20)
    ;//Do nothing

I've patched a local copy of your fork, and it seems to repair transmissions in both ways. Have fun with it!

The question remains: why is the packettx() callback coming before the end of the packet transmission? Self assigning this issue to figure that out, and I'll close the ticket only after the mystery is solved.

73 from Knoxville, --Travis

notpike commented 5 years ago

Cool! Thank you for your help. :D