Shop OBEX P1 Docs P2 Docs Learn Events
27937 Datalogger problems. — Parallax Forums

27937 Datalogger problems.

Istha PowronIstha Powron Posts: 74
edited 2009-03-24 21:50 in BASIC Stamp
Does anyone actually have the data logger working with flow control?

I am trying to interface it with the Javelin and though I have been given enormous help from Peter V, I just can not get the thing to work.

I have read every post on the logger and they all point to the same thing that people sort of get it working and the sample progrems fail at different points.

I have put a scope on the outputs and it would appear that the thing just starts transmitting data for no apparent reason. Has anyone else seen this?

As well, can anyone explain these lines of the sample programs?

' For Synchronization send E until echoed back
DO WHILE (index < 1)
PAUSE 500
SEROUT TX\CTS, Baud, [noparse][[/noparse]"E", CR] ' Transmit "E CR"
GOSUB Get_Serial_Bytes ' Get Returned Data
LOOP
GOSUB Purge ' Purge Buffer

' Send e to complete synchronization
PAUSE 500
SEROUT TX\CTS, Baud, [noparse][[/noparse]"e", CR] ' Transmit "e CR"
GOSUB Get_Serial_Bytes

Here are my queries;

I understand that you send 'E' to it until it syncs; why do you then send 'e' and where in ANY documentation does it tell you to do this? The manual suggests that either 'E' or 'e' ;

‘E’<cr> ‘E’<cr> Echo This will return ‘E’,$0D for synchronisation purposes
‘e’<cr> ‘e’<cr> Echo This will return ‘e’,$0D for synchronisation purposes

When you sync with 'E' it actuall returns;

Ver 03.64VDAPF On-Line[noparse]:D[/noparse]evice Detected P2No UpgradeD:\>

Which is a lot different to ; ‘E’,$0D


So what return should one expect from 'e' ???

It appears that you get a different response every time you talk to it and then becomes totally unresponsive. (and yes, I am clearing the buffer frequently).

Is it me???? Or is this just a difficult piece of hardware to make work?

Istha

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
Adam Smith

Comments

  • Tracy AllenTracy Allen Posts: 6,664
    edited 2009-03-23 19:37
    I never use the "E" and "e" business, and I don't understand precisely what it is for either. I cornered two FTDI engineers at a technical show last year, and they didn't have an explanation for me beyond the weak lines in the documentation.

    I synchronize by having control over the power to the device, which I need anyway to manage the power budget. The simplest synchronization is to simply turn the device on, and then SERIN with a WAIT("D:\"), and with a timeout to catch any error condition. Without the power control, a series of CRs sent to the device at several second intervals may also eventually invoke the D:\ prompt--Although there are some modes it can fall into that do not respond to anything but a cold start. Those modes can be avoided in a polished program, but are a hazard during development.

    If you got "Ver 03.64VDAPF On-Line[noparse]:D[/noparse]evice Detected P2No UpgradeD:\>" instead of the "E", it probably means that your program is not delaying enough time for the drive to initialize. It will always put out that message at power-up, before it is ready to respond to commands.

    One trick about the flow control concerns sending substantial amounts of data (greater that about 25 bytes) in one SEROUT. The logger expects the flow control in the other direction to be in the ready state (RTS=low), even though it does not actually send any data back. Be sure to get the CTS and RTS connections wired and configured correctly in the firmware. It is easy to get confused!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • Istha PowronIstha Powron Posts: 74
    edited 2009-03-24 04:03
    Thank's Tracy,

    What you are saying is that this is (as we would say in Australia) one dodgy piece of hardware.

    I am making slow progress with the help of Peter V who is also having problems getting it to work. If he can't.....

    Your comments about the 25 Bytes scare me. I am attempting to use this to log data from a GPS which comes in at about 125 bytes a second. By the time I have written to the USB and waited for its response five times, I'm going to start losing the data.

    You say the flow control has issues. I note a few posts where people suggest you simply not use the flow control.

    Do you think there is any chance this thing can be relied on to record data comming in at 125 Bytes a second?

    I

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





    The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
    Adam Smith
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2009-03-24 06:37
    Keep the RTS line from the Stamp (or Javalin or Prop) low while sending data to the logger. There is no 25 byte limit and it should be able to handle the 125 bytes/sec.. Bring RTS high again right after finishing, because that reasserts flow control so that the Stamp can receive the response. This is not an issue on a processor that has a full duplex serial port (Prop or PC for example).

    The data payload your program sends to the logger can be quite long if you want, and occasionally you may see the CTS flow control from the logger back to the Stamp flicker briefly low as it writes a flash page. The Stamp cannot send data fast enough to make serious inroads on the loggers serial input buffer. That would be different with a faster processor. I'd stick with implementing the flow controll.

    If your program says is is going to send x characters in one payload, the logger will wait patiently until it receives all those characters, so make sure the count is correct. That is sometimes easier said than done. If it seems to lock up, then sending a string of "E"s or CRs or anything at all will eventually satisfy the character count and it will return to the prompt.

    I haven't had much problem with writing dstuff from the Stamp to the logger. In my experience, reading from the logger is dodgier than writing to it. The Stamp implements its flow control on a byte by byte basis, no buffer at all, and under some conditions, the Stamp flow control is not quite fast enough as a gate keeper to stop the logger from sending two characters head to tail. No serial input buffer=no cushion for missed bytes.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2009-03-24 18:55
    As a note, I have used the Datalogger in several applications, including a GPS logger where the data is stored directly in KML format for use by Google Earth. To date I haven’t had any issues with the Datalogger, flow control, or the like. I did find two USB Thumb Drives that the Datalogger (Vinculum Firmware) did not like. I can also tell you that many Secure Drives may not be supported because of the way their firmware handles the connection to the host. Take care.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Engineering
  • Istha PowronIstha Powron Posts: 74
    edited 2009-03-24 21:50
    Thank's Tracy, I'll give it a go [noparse]:)[/noparse]

    Chris, I'm really happy that you have had no problems with the datalogger, that's helpful advice.

    I

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔





    The robot is going to lose. Not by much. But when the final score is tallied, flesh and blood will beat the damn monster.
    Adam Smith
Sign In or Register to comment.