I am experimenting with the BMP5 protocols and my CR1000 loggers. I got the idea from this forum -- I saw a discussion of the http://sourceforge.net/projects/pypak/ project, then I grabbed a copy of http://www.campbellsci.com/documents/manuals/bmp5-transparent-commands.pdf.
The background on this is that I want to get data from a CR1000 to a linux machine. We already have a LoggerNet for Linux license, but it's overkill for what I want from it (one linux box, one CR1000, no "remote" computers), so I've been looking for simpler alternatives.
My first problem is that both PyPak and the BMP5 manual's Java example (appendix D) deal with TCP communications (via the python or Java "socket" packages). Both have comments to the effect that the same logic could be used with serial streams, but that's about the end of it.
My initial testing with TCP sockets has been fine, the examples included in PyPak work exactly as advertised. But my fumble-fingered attempts to swap out "socket" for "serial" (I am using the pyserial python package) have led me to this question:
Does the RS-232 port on the CR1000 need to "wakeup"? Could it be dropping the first few serial packets it receives after a period of inactivity?
Through trial and error, I have found that the first command that I send to the CR1000 gets no reply. But if I send it a \xBD (SerSyncByte), sleep for 0.5 seconds, and then send a command, everything is peachy. At least in my limited testing, this has reliably resulted in complete replies from the logger. But I'd rather not waste all those half-seconds if I don't have to.
[I learned this totally by accident. I'd been completely unable to get a reply from the logger via serial, and I just happened to throw it the same command very quickly twice in a row, which to my amazement resulted in a reply the second time.]
On the TCP side I do not see this behaviour. [I am connected by IP and port number to a Raven X cellular modem that is in turn connected to the RS-232 port of a CR1000.] The first command may or may not get a quick response but there is no loss of packets on the TCP side and the logger will eventually reply. Subsequent commands in short order usually are answered right away.
In both cases the CR1000's RS-232 port is set to "115.2K Auto," which I believe is the factory default. I have experimented with various Fixed and Auto baud rates but I cannot eliminate these lost packets altogether. The computer is sending commands at 38.4K 8N1 with no handshake.
Can anyone throw light on why the socket/modem/logger route always seems to work fine but the serial/cable/logger path is picky about what commands it will answer? Is it possible that the logger is dropping packets on the serial side, and is there anything I can do to prevent this?
I should mention that if I can get this working by RS-232 and cable, my next trick will be via two RF401s and the CS I/O port on the logger. [That's why I've been testing at 38.4K baud.] But I haven't tried that yet.
thanks,
Mike J+
A quick reply (an expert may follow on): for direct serial communications the logger does require some characters to wake it up along with a series of Serialsync characters to allow it to sync to the baud rate. This is normally achieved in Pakbus by sending a "ring" packet referenced in the manuals you have. This has a stack of 0xBD characters in it.
If you want the fastest initial response you can set the logger to leave its serial port on permanently (at some cost in current consumption) and fix the baud rate to that you intend to use.
There is not such a requirement if the logger has a TCP/IP connection (as the serial port is left on all the time and a permanent PPP session) or has an SDC connection (which includes the RF401 if configured normally as the baud rate is preset).
doh! I guess I should have rtfm. In retrospect I was trying to answer "why isn't this working via serial?" when I probably should have been asking "why IS this working via socket?" But there it is at the top of Chaper 4 of the BMP5 manual. Thanks.
I have a few followup questions, if you'll bear with me.
I have now begun testing communications via RF400s (not RF401s, since I only have one of those on hand) connected to the CS I/O port, and it seems like I might need to keep the radios awake too. What tools or setting will I find useful in keeping the logger and radios awake throughout a given conversation with the logger?
I am assuming my communications should look something like: Ring (repeat until Ready is received), Hello, <some interaction>, Bye. How long should I wait for a reply before trying to ring again? If I wait too long, it seems like the various players might fall asleep again.
Would it help to use the "expect more" code in the packet headers? The sample "ring" packet in the manual has an "expect more" of 0, which seems really odd to me, so I'm wondering if it means anything. I would expect a "ring" would always be the prelude to further communications, which to me says "expect more" = 1.
How long will the CR1000 continue to listen after a successful exchange of Hellos? Does it make a difference if I'm directly connecting to the RS-232 port vs. connecting by Radios to the CS I/O port? I see a reference to "40 seconds" in the CR1000 manual but I'm not sure if I'm reading it right, and anyway *something* is timing out much more quickly than that in my setup.
Should I try to force the radios to stay awake until my transaction is done? I've left them both on Standby < 4mA mode, but I've experimented with doubling their Times of Inactivity to Sleep to 100 (10 s) and their Times of Inactivity to Long Header to 96 (9.6 s). But something is still timing out, I can't tell whether it's the CR1000 or the radios.
Mike J+
I have now begun testing communications via RF400s (not RF401s, since I only have one of those on hand) connected to the CS I/O port, and it seems like I might need to keep the radios awake too. What tools or setting will I find useful in keeping the logger and radios awake throughout a given conversation with the logger?
The RF4xx receiving radio moves between a state where its receiver is in a low power state to where the receiver is ready to receive. The rate and duration at which this takes place is governed entirely by the radio settings. When the transmitter is ready to transmit, it will send out a transmission header which, if the radio settings are matched, will be of a duration long enough for the receiving radio to recognise that it should keep its receiver active. The receiving radio will then keep its receiver active until a period of time specified by its "Time to Sleep" setting is expired (anywhere between 200 to 800 msec).
The RF400 knows nothing about PakBus framing so you are entirely at the mercy of the radio protocol. The upshot of this all is that the radios can introduce a latency of anywhere between 100 msec to 8100 msec depending upon their configured power mode. You must take this into account when calculating the amount of time to wait for a response before retry.
I am assuming my communications should look something like: Ring (repeat until Ready is received), Hello, <some interaction>, Bye. How long should I wait for a reply before trying to ring again? If I wait too long, it seems like the various players might fall asleep again.
The LoggerNet server will use a delay of anywhere between 600 msec to 10 seconds depending upon the intrinsic delay that it assigns to link devices and specified extra response time.
Would it help to use the "expect more" code in the packet headers? The sample "ring" packet in the manual has an "expect more" of 0, which seems really odd to me, so I'm wondering if it means anything. I would expect a "ring" would always be the prelude to further communications, which to me says "expect more" = 1.
The expect more code has significance only when a full PakBus header is used since it relies on the source and destination end-point addresses and not the source and destination physical addresses. When transmitting complete messages, the LoggerNet server will set this value to 1 (expect more from this direction) as long as there are transactions pending for that destination address. Once those transactions are complete, the LoggerNet server will transmit a final message (with no message type or transaction number) that will initiate the shut down of the link.
How long will the CR1000 continue to listen after a successful exchange of Hellos? Does it make a difference if I'm directly connecting to the RS-232 port vs. connecting by Radios to the CS I/O port? I see a reference to "40 seconds" in the CR1000 manual but I'm not sure if I'm reading it right, and anyway *something* is timing out much more quickly than that in my setup.
Once the datalogger has published a "ready" message, it will keep that neighbour link open for up to 40 seconds without sending anything else. It will not stay in that ready state, however, unless there is an active expect-more session to keep it open (this session also has a life span of 40 seconds). If there is no such session, the datalogger will publish a message with a "finish" link state and will shut down its side of the link much faster than the forty second expiration time (I'm not sure of the exact time).
Should I try to force the radios to stay awake until my transaction is done? I've left them both on Standby < 4mA mode, but I've experimented with doubling their Times of Inactivity to Sleep to 100 (10 s) and their Times of Inactivity to Long Header to 96 (9.6 s). But something is still timing out, I can't tell whether it's the CR1000 or the radios.
The values that are used for the four standby modes recognised by DevConfig were arrived at after mush careful experimentation and consideration by the engineer that designed the RF400 as a way of balancing responsiveness with low power requirements. We know from painfully earned experience that these combinations work and that other combinations can render the link useless. If you wish to ignore that experience, you had better understand exactly what you are doing.
I don't buy the argument that LoggerNet/Linux is overkill for what you are trying to do. I may be somewhat biased here since I am its author but it represents an enormous investment of work and painfully gained experience and it pretty much works. I have not looked overly closely at the code for PyPak but my initial impression was that it is rather naive and is likely to fail (as you are apparently seeing) when it has to work with anything other than a direct connect. My personal feeling is that you will likely be time and money ahead with LoggerNet.