Hello,
I am sending 14 serial data packets out of one of the COM ports in the CR1000 datalogger to a end-device PCB at the top of every minute. The serial port is configured as TTL, binary, 8 data bits, 1 stop bit, no parity, at 115,200 bps. Every once in a while I was having some timing problems that were causing an interrupt time-out in my end device which was caused by a delay, greater than expected, between characters in one of the packets. I connected a scope to the serial TX of the datalogger to monitor the data that was being sent out and monitor the time between the characters in each message. After leaving it running for three days or so, I found that in numerous occasions there was a delay between two characters of a single packet from 2 ms to a max of 20 ms in some situations, where in normal packets the delay between characters is between 80-100 us.
The 14 packets are not sent in any order out of the datalogger and from what I recorded, the delay does not happen in the same packet, as far as order is concerned. What is interesting though is that the delay always occurs between the same character position in the packet. In every single case that a delay was captured by the scope, the delay always occurred between the 8th and 9th character of a single packet.
Any thoughts?
Thanks.
The logger runs a multitasking system so you can get delays in things happening in the range of a few milliseconds to a few tens of milliseconds if the tasks involved are deemed to be not high priority, e.g. processing tasks.
There are ways to avoid delays between measurements and some serial output which is to force the logger to run in pipeline mode and for serial output to use the serialoutblock command. This only works for certain com ports - please see the CRBasic help for more information.
Hi Andrew,
I am using SerialOutBlock as the command to send data out the serial port. The program runs in sequential mode, so according to the help files, this instruction should be running from the processing task sequencer. However, I'm not making any measurements in this datalogger so I don't have any measurements instructions in my program that would be of higher priority, I would think. What the program does is accept data from remote dataloggers, via TCP/IP, and after data is stored to the tables (using AcceptDataRecords), it triggers a sequence (in a slow sequence scan) that builds the packets and sends them out the COM serial port using SerialOutBlock. I also find it odd that the delay always occurs in the exact same character position of a message.
If the program is in sequential mode then the serialoutblock is treated with the same priority as processing. Processing has a low priority and falls alongside the communications tasks in priorities. This means communications activity, especially TCP/IP comms (including low level traffic, e.g. ARP), can throw in delays in the processing activity.
The multitasking system works on a time slicing basis with a recirculating queue and 10 ms time slots. This does mean things can happen in bursts of activity for fixed periods. This will likely be the explanation why you get repeatable bursts of data and then delays when the system is busy.