Silvercrest SL-65
Data retrieval experimentations

Disclaimer

This information is the result of analysis.
There is NO guarantee of accuracy. You use or abuse this information at your own risk. Same goes for the software.

 

Why?

I originally downloaded the SL-65 stuff from the Comag website. This absolutely refused to work. Lovely.

Ewen found for me the proper Silvercrest website which had tools for the Silvercrest version of the SL-65. Thanks Ewen!

Great! AliEditor connected to my receiver, so I could now back up the firmware, and be able to look at the channel listings.
It was a good idea, and might have worked had the dopey software not decided upon creating a zero-length dump. Lovely!

 

Where do we go from here?

If their own software won't work - then we'll have to snoop the serial transfer to see how it works, and then try to roll our own data capture. I suspect that the problem is either a bad incompatibility with my computer, or the insanely fast serial connection (115,200bps is quite fast!) is overflowing the boring "generic" serial hardware.
Either way, it is annoying of ALI/Silvercrest not to have sorted this in their own program - doesn't the receiver obey RTS/CTS?

 

How it works

Nicely, you can forget the snazzy-looking menu upgrade options. The receiver, when switched on (not in standby) will obey commands sent via the serial port.
There doesn't appear to be anything that I've found that talks to the receiver while you're in the "upgrade" menu; which is a shame as maybe that would support a more reliable mechanism for sending/receiving data. Can anybody help?

The available commands (looking in the firmware dump) appear to be:

This is for reference ONLY - trust me, you don't want to fiddle and find you've mistakenly told the receiver to dump the memory contents (which may be random) into the FlashROM!

 

The transcript

For the following discussions, please refer to this transcript:

Data read from the receiver is marked in light blue.
Data written to the receiver is marked in light read.
It appears that the receiver may echo some stuff.
 
The leftmost column describes the operation.
The next column shows the data in a cooked ASCII form.
The right column shows the data in hex, with 0x prefix so you know.

Set buffer RxSize: 4096 TxSize: 0
Set state Flags: fff Baud: 115200 Bits: 8 Stop: 1 Parity: Even
Set buffer RxSize: 10000 TxSize: 10000
Write byte c0x63
Read byte c0x63
Write byte o0x6F
Read byte o0x6F
Write byte m0x6D
Read byte m0x6D
Write byte t0x74
Read byte t0x74
Write byte e0x65
Read byte e0x65
Write byte s0x73
Read byte s0x73
Write byte t0x74
Read byte t0x74
Write byte 0x20
Write byte .0x0D
Write byte c0x63
Write byte .0x0D
Read 14 bytes APP init ok.. 0x41 50 50 20 20 69 6E 69 74 20 6F 6B 0D 0A
Write byte c0x63
Write byte .0x0D
Write byte c0x63
Read byte .0x0A
Write byte .0x0D
Read 11 bytes >:..>:c..>: 0x3E 3A 0D 0A 3E 3A 63 0D 0A 3E 3A
Write byte c0x63
Read byte c0x63
Write byte o0x6F
Read byte o0x6F
Write byte m0x6D
Read byte m0x6D
Write byte t0x74
Read byte t0x74
Write byte e0x65
Read byte e0x65
Write byte s0x73
Read byte s0x73
Write byte t0x74
Read byte t0x74
Write byte 0x20
Read byte 0x20
Write byte 10x31
Read byte 10x31
Write byte 00x30
Read byte 00x30
Write byte .0x0D
Read byte .0x0D
Write byte a0x61
Read byte a0x61
Write byte l0x6C
Read byte l0x6C
Write byte i0x69
Read byte i0x69
Write byte 0x20
Read byte 0x20
Write byte 0x20
Read byte 0x20
Write byte D0x44
Read byte D0x44
Write byte V0x56
Read byte V0x56
Write byte B0x42
Read byte B0x42
Write byte -0x2D
Read byte -0x2D
Write byte S0x53
Read byte S0x53
Read 3 bytes .>: 0x0A 3E 3A
Write byte d0x64
Read byte d0x64
Write byte u0x75
Read byte u0x75
Write byte m0x6D
Read byte m0x6D
Write byte p0x70
Read byte p0x70
Write byte .0x0D
Read byte .0x0D
Read 4 bytes . .. 0x00 20 00 00
Write byte O0x4F
Read byte ã0xE3
Read byte .0x00
Read byte .0x00
Read byte .0x10
Read byte .0x00
Read byte .0x00
Read byte .0x00
Read byte .0x00
Read byte .0x00
Read byte .0x01
Read byte .0x00
Read byte .0x00
Read byte N0x4E
Read byte C0x43
Read byte R0x52
Read byte C0x43
Read byte b0x62
Read byte o0x6F
Read byte o0x6F
Read byte t0x74
Read byte l0x6C
Read byte o0x6F
Read byte a0x61
Read byte d0x64
Read byte e0x65
Read byte r0x72
Read byte .0x00
Read byte .0x00
Read byte .0x00
Read byte .0x00
Read byte Dump continues...

 

Analysing the transcript

Before we look at what actually happens in the transcript, we should take a moment to reflect on the messages that appear on the display of the receiver.
The receiver needs to be on in order to make a serial connection, so initially the display will show the channel number - something like "0001".
As the connection is initiaised, the receiver will restart (the display will briefly say " on ") however the video and audio outputs will remain blank.
The display will flicker to say "conn" for a split second and then you will see two vertical bars in an alternating sequence ("| | ", then " | |").
This alternating pattern will continue for the duration of the transfer, and once the transfer is complete (about four minutes), the bars will stop moving (a constant "| | ").

Therefore...

It appears that we begin the process by outputting:
   comtest [0D]c[0D]
to a serial port running at 115,200bps with the protocol of 8 data bits, 1 stop bit, even parity - usually abbreviated to "115200 8E1". Note - 8E1, not 8N1.
Just in case clarification is required - the values in square brackets that are italicised (for example "[0D]") are hex bytes.

The receiver would appear to echo the "comtest" but not the final four bytes.
The receiver will reply with:
   APP init ok[0D][0A]
 
We then output:
   c[0D]c[0A][0D]
Note that the CRLF sequence is reversed.
The receiver then replies with:
   >:[[0A][0D]>:c[0A][0D]>:
Again, note that the CRLF sequences are reversed.
 
At this point, the front panel LEDs will say "ASH ". This is only visible when using my software as I have longer time-outs than AliEditor.
 
We now send the command:
   comtest 10[0D]ali DVB-S
to which the receiver replies with a command-line of sorts:
   [0A]>:
 
At this point, the front panel LEDs will say "conn".
 
We send the command:
   dump[0D]
The receiver replies with four bytes:
   [00][20][00][00]
In little-endian (Motorola/ARM) byte ordering, this equates to "1<<16" which is 2,097,152 - or two megabytes. This is probably the size of the dump that is to be returned.
 
At this point, the front panel LEDs will say "dup ", but you don't normally see this when using AliEditor.
 
We then output:
   O
(upper case 'o', perhaps for "ok"?)
 
The receiver will then reply with loads of data. A complete dump of the 2Mb FlashROM.
 
It appears that there is no official 'finish' to the transfer, and currently if you don't catch all the data in time, stuff gets missed.
 
I have my suspicions that AliEditor may be abandoning the transfer due to the speed of the serial link. Let's put it like this - I regularly transfer files to/from my RiscPC at 115,200bps using HyperTerm and HearSay2. Sending to the 40MHz ARM is no trouble whatsoever - the RiscPC can more than keep up.
Returning data (from the 40MHz RiscPC) to the 466MHz Celeron PC results in numerous retries and communications errors. It will work, as Zmodem is robust, but it appears the PC frequently loses bytes.
Now, I know you cannot compare clock speeds of a RISC and a CISC processor, and I know one is running a hand-crafted assembler operating system and the other Windows... but whichever way you slice the cake, the brute speed of the PC is eleven times faster, not to mention a memory subsystem probably clocking around 66MHz (instead of the RiscPC's 12MHz bottleneck).
Anyway, the point isn't to slag off the x86's interrupt latency or Windows serial port handling, the point is to try to come up with reasons why AliEditor is not working for me - as surely if it simply does not work, somebody at Silvercrest might have noticed by now!

 

Putting this in action

My version of VisualBasic (5LE SP3) is not licenced to use the COMM control - boo-hiss. Additionally, I wanted something to run outside of Windows.
Therefore, I present a 16 bit DOS executable that requires direct hardware access (in other words, don't run it via XP/Vista) plus the source code and project files for Borland TurboC++.
BUG WARNING: The interrupt vector claimed is 0x0C for COM1. Due to a peculiarity (most likely historical) in the way PCs work, COM2 uses a different vector. SO IF YOU ARE GIVEN A CHOICE - DO NOT USE COM2.
Of all my computers, and those of friends living nearby, nobody has a COM2, so I cannot fully test that my vector code works; thus I will - in the near future - remove the choice and make this software work only with COM1. It makes things a lot easier!

Download "sl65_002.zip" (35Kb)
Distribution/modification licence in the included ReadMe.txt file.

 

Read the source code now! (39Kb)

 

Spot the wally!

I had been under the incorrect assumption that the serial interface implemented hardware handshaking all by itself. It turns out, from reading the spec, that we have to fiddle RTS outselves - so I will need to insert flow control...

 

Modifications to bring the code to v0.03

There is no official code or source release for version 0.03. This is mainly because either my RTS handling is completely whacked, or the receiver ignores flow control after all...

Here are the changes required to update v0.02:

There are other minor tweaks to comments (i.e. line 206, "OUT1" updated to read OUT2 like it should), but these do not affect the functionality of the software...

Serial port setup could be improved by disabling interrupts around the setup code (using disable(); and enable();). As it happens, this makes little difference, and I am not happy about disabling interrupts unless it is absolutely critical.

FINALLY - go to the compiler options and ensure that the choice for "Register variables" is off. I had, previously, set it to automatic. It appears that the compiler may generate bogus interrupt handling code if this option is incorrectly set.
It seems to make little difference in practice, however the built-in help explicitly states: When you use the interrupt keyword, the Stack warning checkbox should be unchecked (off) and the Register Variables option should be set to None.

 

 


Back to non-Sky receiver index · Digibox main index


Copyright © 2007 Richard Murray