Silvercrest SL-65
Data retrieval experimentations

Disclaimer

Why?

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?

How it works

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

• address
• b
• burn
• c
• comtest
• dump
• move
• reboot
• transfer
• transferraw
• version

The 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.

Analysing the transcript

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 that the receiver appears to blindly spit data out its serial port paying scant regard to RTS/CTS handshaking. 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