Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

Configuring Data Logger For Serial Input/Output


Quinton Kirsch Feb 14, 2023 08:31 PM

I have a visibility sensor that uses asynchronous RS-232 and only outputs data when polled. I'm using a CR23X and wanted to know if it were at all possible to send and receive data (poll and receive subsiquent data) without the use of an RTS line. TX, RX, and GND are the only lines available from this device. Appendix B in the logger manual talks about configurations for sending and receiving data but I was not sure if there was a way to get it working without. I know the CRBasic language is far easier to accomplish these sorts of things but am trying to use what I already have - even if Edlog is tedious.

Any help is appreciated!

Edit: I figured it out. Will be responding to this with an in depth explination of what I did so others who may be in a similar situation have supplementary information to work off of.


Quinton Kirsch Feb 16, 2023 05:44 PM

Using a CR23X and R. M. Young 61302L barometric pressure sensor for testing purposes. Communicating asynchronously RS-232 ASCII @ 9600 baud. The transducer is configured to read when polled with command "M0!". This setup was used to simulate the eventual visibility sensor I have planned to integrate. Using a variant of Configuration 4 listed in Appendix B of the CR23X manual, only without the use of an RTS line.

61302L RX to CR23X C5

61302L TX to CR23X C6

I found when exclusively using the poll command, the sensor would output and the logger would "read" data, but it would only report as -INF. After some trial and error I found adding a negative ASCII character to this string would give the sensor time to send the string after polled - or the logger time to read. Instruction 15 Parameter 6 goes into more detail about this. Says adding this extra character - regardless of number so long as it's negative - will add a 150ms spacing condition "break". I guess what this does is allow time between the poll and data logger read of the sensor.

M0! ASCII Decimal Equiv; 77 48 33
BREAK Character -1

POLL STRING INLOCS:
RMY_POLL_77
RMY_POLL_48
RMY_POLL_33
RMY_POLL_-1

5: Port Serial I/O (P15)
1: 1 Reps 2: 4 -- RS-232 ASCII, 9600 Baud 3: 25 Delay (0.01 sec units) before TX 4: 5 No RTS/DTR, C5 TXD/RXD 5: 1 Start Loc for TX [ RMY_POLL_77 ] 6: 4 Number of Locs to TX 7: 13 Termination Character for RX 8: 10 RX Buffer size or Max Chars to RX if Par 2 indexed (--) 9: -1 Wait for RX Termination Character or Max RX Characters ; 10: 5 Start Loc for RX [ RMY61302L ] 11: 1.0 Multiplier for RX 12: 0.0 Offset for RX

For all intents and purposes, the visibility sensor will be read at maximum one time per minute and requires only a single poll character, unlike what's listed above. For this test however, I was polling at a frequency of 1s. I found if the TX Time Out for Parameter 3 was not high enough, the number of values logged would severely drop off and report missing scans to an unacceptable level. Logger did not classify them as overruns but it would record something along the lines of:

RECNUM
1 2 3 4 11 12 13 32 33 34 35 36 37 58 59 60

Found that making the logger delay before sending the command 0.25 seconds seemed to solve this issue.

I did find that when things appeared to be set up correctly, the logger would get hung up and start to overrun scans. Without fail after a couple hours each time I tried the program would - what I can only assume to be a result of lacking RTS line - start spitting out overrun counts and max out to eventually the program seizing up.

To try and find a solution to this seemingly unresolvable problem I tried but not at length to use the switched power 12V supply, where the idea was to:

1. Switch on 12V
2. Wait X seconds with "TX Time Out" to allow sensor to warm up
3. Send poll command with break
4. Read sensor data
5. Switch off 12V
6. Execute remaining program Repeat -->

So that in theory the device would "reset" each time power was applied so that the timing between poll command and data receival would always remain constant, to perhaps eliminate any possibility of program hang up. And sure it worked, I was only logging at 10s intervals however, and anything faster would most likely be impractical. And to add onto this, I know these functions are probably not being used for their intended purpose. I'd assume using the poll and switching power features are for super low power applications where every mA counts. 

Now obviously this is not a practical solution for a visibility sensor which requires power on at all times. And powered via 120V AC for that matter. Maybe it's a logging frequency thing? I don't really know. Maybe someone out there has an answer to this problem.

It's probably something as simple as ensuring times between poll and data read are well accounted for so there's plenty of leeway.

Again, any help/advice/suggestions are appreciated!

Log in or register to post/reply in the forum.