Proton BASIC Community

Bit of a long shot!  Any ideas please?

I have been asked if I can replicate a 25 pin printer port hardware dongle from 2007 because the original equipment manufacturer is no longer around.  There are several computers in the setup and each dongle determines what part of the system is available to each individual PC.  This is the master dongle which gives full access.

The attached is a snip of the captured data.  So far the captures are the same each time the PC is booted so that is one problem solved.  Orange and red are information from the PC and blue is the returned data.  The whole dongle activity is 11.5 seconds and the smallest data bit period is 10uS.

The problem is that the data from the PC does not appear to follow any particular coding method that I know. 

This is the full capture if anyone is interested enough to install KingstVIS available here http://www.qdkingst.com/en/download

At the top right clicking on the three bars opens the 'load' option.

Dongle activity starts at about 15 seconds when Channel 15 goes high.  Zoom in or out using the mouse wheel anywhere over the data screen.

Assuming that sequence is being generated by the application software, and you're saying the challenge/response sequence to/from the dongle is identical, then that's a terrible implementation.
First thing I'd do is advance the PC date by a few years to see if the sequence is the same.

Anyway, if it's decided that the sequence never changes, then it should be a simple-ish matter of using a PIC to generate the correct response.
Count the number of positive going red pulses, and generate an equivalent blue pulse.

Quote from: See_Mos on Sep 09, 2024, 10:23 AMThe problem is that the data from the PC does not appear to follow any particular coding method that I know.

Maybe you have already considered this or there seeing a large amount of the data would dismiss the following, but...

Although it is a little odd with the dead periods gaps (could be a wake up sequence) at the beginning and the occasional long pulse (may be down to sampling frequency) could the Red signal be a clock rather than data as it mostly has that look about it?

If so then I would think that as you stated the Orange would then appear the be data to the dongle.

The initial two blue single pulses could be an Ack signal from the dongle back to the PC as unless I have miscounted there does appear to be 9 Red pulses between them which would make sense if the Red is indeed a clock (8 for data + 1 for the Ack). Thus, considering that may be the case thereby giving you a delimiting point to discern each byte of Orange data perhaps looking at that as hexadecimal values instead of as a waveform it may then resolve into know control codes.

QuoteAssuming that sequence is being generated by the application software, and you're saying the challenge/response sequence to/from the dongle is identical, then that's a terrible implementation.
First thing I'd do is advance the PC date by a few years to see if the sequence is the same.

The dongle is not for software protection more to stop unauthorised users accessing the wrong part of the system.  The whole system is networked and each part of the system has its own dongle so that for example a camera operator does not have access to the crane operator stuff, only the PC with the master dongle has full access, so the simple implementation and date are not a problem. The dongle check is only done once at start-up.

QuoteAnyway, if it's decided that the sequence never changes, then it should be a simple-ish matter of using a PIC to generate the correct response.
Count the number of positive going red pulses, and generate an equivalent blue pulse.

That was my first though. I could not see any logical breakdown but I think I will try. There are about 59,000 negative going edges on the red channel so roughly 7500 bytes which should be doable but that's a big array of bytes.

@Stephen, the ACK sequence does seem to appear several times though I did spot one or two where the red and orange pulses are not the same.  I will try to break it down further.

I need to find out if the installation for the software is available as the setup provided by the end user is running under Windows XP and the only way to reboot the software is to shut it down via task manager then rebooting the PC which takes minutes to complete.

This is what happens without the dongle.  Capture starts after the NOT Select Printer line goes high.

The request ACK happens 12 times then there id activity on other lines of data from the PC that are not active if the dongle is present.

At first the capture looks like 3 wire SPI but there is an odd clock that appears many times throughout the capture. I tried to decode the data on the orange (data out) and blue (data in) lines, using red as clock, but the odd clock pulse upsets an eight bit decode.  The odd clock is always preceded by two low pulses on data out which does not make sense for a standard data storage device.  The timing of the odd clock is not consistent so using a timer to eliminate the pulse did not work.

The next step is to try and capture the blue data sequence and see if I can fool the system by syncing against the clock pulses. I think this should work as long as the return data is always the same.

There are over 3,200 bytes so I don't have many options. I have ordered some FRAM meanwhile I was wondering if it might be possible to use the internal flash memory of a PIC, ideally 18F25K22. I have searched the help file but cannot find a way of storing so much data 'on the fly'.

Quote from: See_Mos on Sep 25, 2024, 09:37 AMThere are over 3,200 bytes so I don't have many options. I have ordered some FRAM meanwhile I was wondering if it might be possible to use the internal flash memory of a PIC, ideally 18F25K22. I have searched the help file but cannot find a way of storing so much data 'on the fly'.

Hello See_Mos,

sorry, can you clarify? Why would you need to store that information in RAM? You can place it in FLASH memory and read it sequentially from there, then send each byte at the appropriate time.

Hi trastikata,
In post #1 I posted a link to the logic analyser software and a full capture of printer port activity when the PC power is turned on. The software does not need the hardware to view the data file.  The first part is the PC looking for a printer then the dongle activity is just orange, red and blue channels.

As the data does not decode because of the random clock pulses my next step is to use the red clock to capture the data from the dongle on the blue channel and save it so that I can transfer it to another device then use the new device to simulate the dongle using the clock from the PC to playback the stored data.

 It might not work but I have restarted the PC many times and as far as I can tell the returned data is always the same

So I am wondering if it is possible to write directly to program memory as there is too much information to use the RAM memory and if I can use program memory it will be retained when power is removed. In the help file CWRITE is shown as a reserved word but there is no further information.

Hi See_Mos,

I see now. I think one way to do it - first capture and convert the stream to byte data table (just like a font table).

- Then add this data table as flash data

- Determine the total length of the stream in terms of number of bytes

- Loop reading through the data table and send the bytes

Example code:

Device = 18F14K50
Declare Xtal = 4

Dim wCounter As Word
Dim bTemp As Byte
Dim dwFontAddress As Dword

dwFontAddress = AddressOf(DataTable)

For wCounter = 0 To 39
    bTemp = CRead8 dwFontAddress[wCounter]
    'Send bTemp as byte with the appropriate protocol 
Next

Dim DataTable As Flash8 = 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,_
0x18,0x18,0x18,0x18,0x18,0x00,0x18,0x00,_
0x6C,0x6C,0x6C,0x00,0x00,0x00,0x00,0x00,_
0x6C,0x6C,0xFE,0x6C,0xFE,0x6C,0x6C,0x00,_
0x18,0x7E,0xC0,0x7C,0x06,0xFC,0x18,0x00


Exactly what I was thinking but first I need to capture all of the data.  Manually breaking it up ready for the font table would be almost impossible.  The FRAM chips should be here soon.  Once stored using the data will be much easier

Is it that much data so it can't fit in the PIC FLASH and you'd need external memory?

My confusion is with the F-RAM - why using it, those are usually expensive and have different purpose than simple data storage?

Get a $10 Cypress logic analyser off Amazon and use Sigrok. You can capture data at 10MS/s with the capacity of your PC storage easily. You can work on the protocol by writing a decoder PC side.

You can then use a DAC or logic-based emulation to emulate the decoded data (output).  I'm pretty sure the PICKIT can manipulate on a bit-bang basis via Sigrok. 

Quote from: trastikata on Sep 26, 2024, 01:37 PMIs it that much data so it can't fit in the PIC FLASH and you'd need external memory?

My confusion is with the F-RAM - why using it, those are usually expensive and have different purpose than simple data storage?

The problem is how to capture and store so much unknown data. If I use RAM it is lost when power is removed or each time the chip is reprogrammed during development.

Is it possible to create an ARRAY of 2K bytes in flash?  If so I can capture and save the incoming data

I have exported the decode as CSV but that will need a lot of editing to get it ready for using in Positron

Quote from: See_Mos on Sep 29, 2024, 01:36 PMThe problem is how to capture and store so much unknown data. If I use RAM it is lost when power is removed or each time the chip is reprogrammed during development.

My understanding was that the data is already captured and you are looking for a way to store that back into FLASH.

Sorry, my mistake. I think easiest and least expensive would be a 16b PIC with more than 20k RAM, log the data and send it all to a serial terminal.

FRAM is certainly fast enough, but I see now the baud rate is about 115200 so it could be a problem the SPI timing. If the 16b PIC is not an option I'd get a 8b PIC with 2 SPI modules and use the hardware SPI interrupt.

Set the FRAM to sequential write and FRAM SPI baud faster than data-in rate. Assuming SPI_1 module is the inbound data and SPI_2 is out to FRAM, at SPI_1 interrupt read incoming byte from hardware register and write it immediately to the SPI_2 outgoing hardware register ... this way you won't have any troubles.

Quote"There are about 59,000 negative going edges on the red channel, so roughly 7500 bytes, which should be doable, but that's a big array of bytes."

For some reason, I couldn't open the capture file, so I cannot see how many ACK cycles are in the whole message.  Surely, you only need to detect the start sequence and then store the number of Red edges that produce a blue edge? 

Start the sequence and read the flash for the number of Red (clk) cycles to wait until you assert the first ACK. Once asserted, read the next number of cycles from the flash, count and assert Ack. etc.  It should be possible to code a PIC to count the red edges until a blue is detected, then send the count to the serial port, where you can generate a flash table in a PC program and send it back to the PIC to store as a flash table.   
 

The file I posted earlier no longer opens for me either, though I did test it after posting to make sure the unzipped file worked.

After playing around all morning I did a higher resolution capture and om zooming close in I can see that the data changes 300 nano-second after either rising or falling edge of the clock so it's not SPI after all.

so now it's back to capturing the data to FRAM using the clock as bit count.

Quote from: See_Mos on Sep 30, 2024, 02:44 PMso now it's back to capturing the data to FRAM using the clock as bit count.

What is the PIC you are using and the hardware set-up, or this can be varied?

Quote from: See_Mos on Sep 30, 2024, 02:44 PMAfter playing around all morning I did a higher resolution capture and om zooming close in I can see that the data changes 300 nano-second after either rising or falling edge of the clock so it's not SPI after all.

Sounds like software bit-banging.

You can use standard flash memory and use a multi-buffer method of capturing the data.

It sounds complex but it is not, it just takes a few largish RAM arrays and a pointer to each one's address, so when one RAM buffer is full, the next is pointed too, and while the data is written to the flash memory's page, the data is still being captured and stored in the new buffer by the same code, but pointing to a new RAM area for a new buffer array, then when that one is full, point to the next RAM buffer etc...

Then when the last buffer is full, point back to the first one, and on and on in a circle around the RAM buffers. It makes capturing data very fast and seemless.

It requires enough buffer RAM to make sure the data is written to the flash before the RAM buffers are all full. And it is better to make each buffer the same size as the flash memory's page, so it can be written in a single operation of just transferring bytes to it. Even a few large buffers may only require about 2K of RAM, and on the newer devices, that is easily done.

I've done this several times for audio and data storage on slow flash memory devices, and SD cards, and it works well.