USB Datalogger Design

SRLM · 2008-10-06 04:53

Okay. I've come to realize that I know nothing useful about the datalogger and how it works with a Stamp, so I'm going to throw the question out there: how does it work? It's a big question, so I'll break it down into some smaller parts. If any of you readers can help me out on even a single part of this, don't be afraid to comment.

First: the buffer? What does it do, and what sort of data is stored in it. Since it's only 15 bytes (as show in the test code), does that mean I have to do things in 15 byte increments?

Second: What does the below code do? I just want my data from the USB drive, not any sort of test data or the like. I see the SERIN command there and wonder what I'm getting...

Get_Serial_Bytes:
  timeout = 1                           ' Set Timeout Indicator Flag
  index = 0                             ' Initialize Index
  DO WHILE (timeout > 0)                ' While Timeout Has Not Occurred
    ioByte = 0                          ' Clear Temporary Storage
    SERIN RX\RTS, Baud, 100, No_Data, [noparse][[/noparse]ioByte]
    buffer(index) = ioByte              ' Save Byte Received To Array
    index = index + 1                   ' Increment Index
    IF (index > 14) THEN                ' Check For Overflow
      index = 14                        ' Prevent Overflow
    ENDIF
  LOOP
RETURN

Third: how does the below code actually purge anything? Seems like if the array needs to be cleaned, then filling it with 0s would be the way to go. Also, for this code and the one above, how is timeout changed to 0 so the control passes outside the loop. I can't see any mention of timout inside the loop.

Purge:
  timeout = 1                           ' Set Timeout Indicator Flag
  DO WHILE (timeout > 0)                ' While Timeout Has Not Occurred
    PAUSE 50
    SERIN RX\RTS, Baud, 500, No_Data, [noparse][[/noparse]ioByte]
  LOOP
  RETURN

Fourth: what sort of stuff in here is dependent on the speed of the stamp. I'm trying to use this on a BS2px, but it seems to freeze at the same spot every time. I did the obvious and changed the Baud rate, but is there something else that I'm missing?

Fifth: Perhaps a solution can be found to one of my other posts, Datalogger Distress.

Unsoundcode · 2008-10-06 18:51

Hi SRLM, I posted a doc once that gave an example of using the logger without flow control, although not everyones choice it does work well.

It is ideally suited for the BS2px at 9600, it fails on the BS2 unless run at a slower speed.

If nothing else it gives good example of some of the common commands, I cant find the post with the lastest version and dont have access to it right now so I am attaching the first draft of the document, it may need a couple of minor alterations like baud rate and the such.

Its important to note that CTS and RTS are not connected to any of the Stamps pins

Jeff T.

Chris Savage · 2008-10-06 19:27

Okay, I’ll bite…I hadn’t realized it was this much of an issue or I would have addressed it sooner. Let’s start with your list of items.

1) The buffer…by looking at the code it is evident that buffer has nothing to do with the Datalogger itself, but is instead an array created in RAM on the BASIC Stamp. As for the size, it could have been 10 or 20 bytes, but we’re limited to 26 total bytes of RAM so we need to find a happy medium. On a BS2p or higher module this could have used SPRAM and been 126 bytes.

2) This probably could have been simplified slightly in terms of the timeout structure, but this code essentially starts receiving bytes from RX pin using flow control on the pin indicated by RTS. The variable index is cleared before entering the loop and the loop will continue until the SERIN routine causes a timeout, at which point it assumes the data is complete. For each incoming byte it is stored in the array (buffer) and the index is incremented by one. If we have 15 bytes the loop also terminates.

3) Okay, so let’s assume in the previous example there were more than 15 characters coming in. Obviously we can’t deal with them. However the next time we read characters from the Datalogger it will still have these in its buffer since we used flow control. So we’d receive them. So a purge is essentially emptying the Datalogger output buffer by receiving (and discarding) any pending bytes it may have. This could also be a response to a command that we don’t care about. Nonetheless we want to purge any pending bytes from it in certain cases.

4) Not sure on this point because I don’t know exactly what is happening or why. I guess there could be some write speed limitation though I doubt the BASIC Stamp could provide enough information fast enough to have that happen.

5) If you haven’t gotten a useful answer to another thread, try following up in the thread with any additional information you may have which might aid others in helping you.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

SRLM · 2008-10-07 03:49

Okay, let me think about this...

1) There are two buffers that we're talking about: a BS2 buffer that we create, and one that is built into the Datalogger (with flow control)? For now, I'll ask about the one on the BS2. Why do we need it? Or, at least, why give it 15 bytes? I'd rather just give it to one, if none of the data is going to be used. The below code shows the way that I've been getting my data. So what's being put into the buffer?

 SEROUT TX\CTS, Baud, [noparse][[/noparse]"RDF ", $00, $00, $00, 12, CR]
 SERIN RX\RTS, Baud, 800, No_Data2, [noparse][[/noparse]largeA.HIGHBYTE, DEC largeA.HIGHBYTE, .... 'And so on

2) What forces the SERIN to have a timeout? Is it just the Datalogger doesn't send any more bytes?

3) More support for the buffer being unneccesary...

Chris said...
So a purge is essentially emptying the Datalogger output buffer by receiving (and discarding) any pending bytes it may have

6) (new topic) What are the numbers indicated in the comments?· Do they mean anything?

TX              PIN     6               ' Transmit Data   --> 27937.4 (RXD)
RTS             PIN     7               ' Request To Send --> 27937.6 (CTS)
RX              PIN     8              ' Receive Data    <-- 27937.5 (TXD)
CTS             PIN     9              ' Clear To Send   <-- 27937.2 (RTS)

Mike Green · 2008-10-07 03:58

1) Part of the reason to have a BS2 buffer is that the Vinculum chip generates responses (messages) to commands and these responses are several bytes long. By reading the whole response as quickly as possible, the Stamp can analyze (or discard) this response easily in the buffer.

2) The SERIN times out when there's nothing received in the specified time. The Datalogger doesn't send any more bytes.

3) See #1

4) Can't help you there. The digit after the decimal point is probably the pin number on the Datalogger.

Chris Savage · 2008-10-07 15:50

The numbers in the comments refer to the part number of the device, in this case the Datalogger (#27937) and the pin number on it that we are referring to in the connection. This is common is code to refer to the actual device and pin in the code, just as you would a port on a microcontroller. i.e. RB.6 on the SX28.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

Tracy Allen · 2008-10-07 16:14

4) 27937 is the Parallax part # for the memory stick datalogger, and the number after the dot is the pin number for that signal. The arrow shows the direction of the signal relative to the Stamp pin.

3..2) After most commands, the datalogger will send out a prompt, which is ">"CR in short command mode and "D:\>"CR in long command mode. You are using RTS flow control with the SERIN command, so after the SERIN has captured all the actual data, the datalogger will still have the prompt in its output buffer. The purpose of the purge is a) to clear that out and b) to check that an error has not occurred. An error either causes a timeout, or it returns an error code instead of the ">"CR. There are many ways to handle the purge. One good way as Jeff has suggested is to eschew flow control, and use a Stamp and/or baud rate capable of capturing all the data without it. With flow control, here is another simpler purge routine, which returns as soon as the normal response is detected, or else times out with an error flag:

V_PurgeSimple:
  SERIN vrx\vrts, vbaud, 2048,v_bad,[noparse][[/noparse]WAIT(">",CR)]   ' allowing ~2 seconds for vDrive response
  vError=0     ' command succeeded, prompt okay
  RETURN
v_bad:
  vError=1   ' error passed back to caller on timeout or other error
  RETURN

1) The datalogger has two buffers, one for receive and one for transmit. The problem on the Stamp comes down to lack of an asynchronous serial input buffer on the Stamp, and timing of the RTS signal. The firmware inside the Vinculum chip sort of assumes that the microcontroller it talks to will have at least one level of buffering for received characters. The RTS flow control works pretty well to hold back delivery of bytes from the vDrive to the Stamp, but it is not perfect. The Vinculum will under some conditions decide to send two characters instead of one, because the Stamp does not assert the RTS "not ready" soon enough. The bottom line is that it is possible to finesse the number of characters requested at once and match it to the data records, and make it work reliably. But I have found that changes in the parameters often lead to new issues that cause data to be lost in transit.

0) I have said this before, but I'll say it again. I think it is important to have means in PBASIC code to have a pin to turn the power to the datalogger off and on. There is no other way I know of to reset the datalogger to a known state. The purgeSimple routine above is sufficient to detect whether or not the drive has passed through the initialization sequence and arrived at the prompt. Also, be sure to download the latest firmware from Vinculum.com.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

USB Datalogger Design

Comments