Cathode mapping weirdness

[Zedsquared]

Hi Tony,
I've built my relay with IN-8-2 tubes and am having trouble getting the cathode mapping right, either I don't understand the command properly or I've got them plugged in wrong, or both!

Here's whats happening:

First I send $13$$PSU,8,12,34,56,78,90,,08*** to make sure I'm starting with a mapping that is straight 1->2 2->2 and so on. I get a blue led blink so I assume all is ok with that.

If I issue 0x13$PSU,7,1,2,3,4,0,0,7*** I see 3456
If I issue 0x13$PSU,7,5,6,7,8,0,0,7*** I see 7189
If I issue 0x13$PSU,7,0,9,0,9,0,0,7*** I see 0202

So my mapping appears to be (desired -> actual) 1->3 2->4 3->5 4->6 5->7 6->1 7->8 8->9 9->0 0->2

So I issue this command to correct the mapping: (essentially inverting the mapping I discovered)
0x13$PSU,8,60,12,34,57,89,,08***

Now I get 1234 -> 0234 5678 -> 5618 0909 -> 9797 ... close but no cigar. The errors are: 1->0 7->1 0->7

What am I getting wrong here?

Cheers,
Robin.

[Tony]

I had to go look in the code to confirm it:


call GPSgetnybbled ;Cats 0,1
andlw 0x0f
movwf Catty1
swapf GPStemp,w
andlw 0x0f
movwf Catty0
call GPSgetnybbled ;Cats 2,3
andlw 0x0f
movwf Catty3
swapf GPStemp,w
andlw 0x0f
movwf Catty2
call GPSgetnybbled ;Cats 4,5
andlw 0x0f
movwf Catty5
swapf GPStemp,w
andlw 0x0f
movwf Catty4
call GPSgetnybbled ;Cats 6,7
andlw 0x0f
movwf Catty7
swapf GPStemp,w
andlw 0x0f
movwf Catty6
call GPSgetnybbled ;Cats 8,9
andlw 0x0f
movwf Catty9
swapf GPStemp,w
andlw 0x0f
movwf Catty8

The instructions are wrong. 0123456789.

[Zedsquared]

Ah, thanks Tony, that expains it, I'll have a try when I get back from work.

Also, TBH, the entire protocol explanation needs some filling in and consistency fixing IMHO... Some things I've guessed or found by experimenting that aren't really explicit in the documentation:

• You'll need a terminal program that can send explicit hex values when requested (I used Bray's terminal) putty or hyperterm won't cut it
• All packets start with the DC3 character which is 0x13 in hex ($13 in Bray's terminal macro language)
• All packets end with three asterisks.
• There are two alternatives for each command, one a "$PSU,command number, parameters..." command and the other more descriptive like "$REL,parameters"

The correction to the remap command still seems a bit dodgy:

08,cat0,cat1cat2,cat3cat4,cat5cat6,cat7cat8,cat9,,08 - $PSU,8,98,76,54,32,10*** Cathode remap. By default is mapped 1:1 for IN-14 eg: 08,01,23,45,67,89,08.

Shouldn't that be:
"08,cat0cat1,cat2cat3,cat4cat5,cat6cat7,cat8cat9,,08 "
Also what's with the ",,08" ending? is it an alternative to "***"? it seems inconsistent with all the other commands.

Random other questions:
Is there any way to tell the colon tube what to display?
Is there any way to query which is the currently selected profile and retrieve it's values?
The description of command 03 doesn't make sense, there doesn't seem to be a way of selecting which of the 'packetBitsx' bytes is modified. How would I go about about setting PacketBits2 bit 5 (Daylight savings) to zero for instance?

Cheers,
Robin.

[Tony]

I have commas in the wrong places from todays change, I'll edit that. Packetbits2 would be bit# plus 8 so $BIT13,0***

The alternative command depends on if it's being decoded by the power controller or base, one version is intended to be more user-friendly while the other is for embedding in a future app.

They're only intended to be temporary until I have a point and click intetrface ready.

[Zedsquared]

I have a properly mapped clock now

For the benefit of any other IN-8-2 kit builders that may follow, the magic incantation is:

0x13$PSU,8,07,12,34,56,89,,08***

Cheers,
Robin.

[Zedsquared]

Alas it seems that cathode remapping doesn't survive a power cycle... This would be *extremely* handy IMHO ... do you have EEPROM space in either of the pics to save this?

Cheers,
Robin.

[Tony]

Plenty of data EEPROM space, it was a deliberate design choice for cases where the user has got in a mess with configuration and can reset by powering down. As it's intended to be permanently powered by the battery pack once in use it shouldn't be an issue.