2

I have to do an application for a GPRS modem JAVA (J2ME) programmable that must interface with an electromedical device (glucometer).

I have an input buffer and an output buffer on the serial port of the device.

When the application starts, I listen on the serial port and I receive from the glucometer one byte with the decimal code "5" which corresponds, to the ASCII table, the symbol of Enquiry and after 15 seconds I get the bytes "4" that corresponds to the End of Transmission.

To receive data from the glucometer I need to send an ACK signal (acknowledge) which corresponds to the byte "6". I tried the following forms:

outBuffer.write("ACK\r\n".getBytes()); //first without setting the charset and after I trying to set all the charset.

I tried to send a byte buffer like this:

byte[] bSend = new byte[] { 6 }; outBuffer.write(bSend); //(I tried also with the byte 10 (LF) and 13 (CR)).

The result is that I can not receive data but I get ​​cyclically but only the values 5 and 4.

With all the software that can comunicate with serial port (like Serial Monitor) if I send an ACK message I receive data from glucometer correctly.

I think my problem is due to the value of the ACK coding in Java, someone can indicate any solution?

dsolimano
  • 8,870
  • 3
  • 48
  • 63
Alessandro Vitale
  • 21
  • 1

2 Answers2

1

As this seems to be a pretty low-level interface that uses ASCII control characters to do its communication I think you need to send these byte values verbatim, and without extra stuff like newlines or whatever. This means that

byte[] bSend = new byte[] { 6 }; 
outBuffer.write(bSend);

Is the correct approach. Now, this protocol looks a lot like ASTM E1381, so I checked here and paragraph 6.1.2 might be related to your problem:

When the meter initiates the Establishment Phase, the meter determines if the computer is connected by initially sending an <ENQ> character. If the computer responds within 15 seconds by sending an <ACK> character, the meter proceeds with Data Transfer Mode. If the computer responds within 15 seconds with a <NAK> character, the meter sends an <EOT> then attempts to enter Remote Command Mode, by looking for an <ENQ> character from the computer. Also see "Section 6.2 Remote Command Mode Protocol". Any response within 15 seconds to the meter’s <ENQ> other than an <ACK> or <NAK> character causes the meter to send an <EOT>, delay one second, then send another <ENQ>. If the computer does not respond within 15 seconds, then the meter sends an <EOT>, delays one second, then sends another <ENQ> and waits again for a response from the computer. Note: One second after sending an <ENQ>, the meter may enter a low power mode. Thus, there is a possibility that the first <ACK> sent by the computer is not read correctly. In this case, the meter responds with an <EOT>, delays one second, then sends another <ENQ>.

Emphasis mine, I guess that that's what's happening. So, you should repeat sending another ENQ to get it into data transfer mode, assuming that that's what you want.

fvu
  • 32,488
  • 6
  • 61
  • 79
  • The situation is exactly the one presented. I have read the same document as having the Bayer Contour XT. I forgot to write before that I send an ACK in a cyclic manner to every message received by the meter, so I don't limit myself to only send an ACK, without results... – Alessandro Vitale Mar 11 '13 at 11:49
  • I am pretty sure the way of sending the ACK byte is correct. If anyways possible have a look at the voltage levels used by your GPRS modem, maybe its Tx signal uses a voltage that cannot be reliably detected by the glucometer (easily done with an oscilloscope - see page 27 of the linked document for the voltage ranges that should work). Also, having a serial port sniffer available would be very handy. – fvu Mar 11 '13 at 12:04
  • 1
    Maybe it helps to call flush()? – mr_lou Mar 11 '13 at 14:30
  • I thank you all for your contributions!Currently I'm not using the software directly on the GPRS modem but through an emulator on my PC. I have tested this emulator, it works correctly because before trying to take data from glucometers I tried to query the GPRS modem with commands that I can also send via shell and I have no problem! I already tried to use the method FLUSH. It's a good idea to use a sniffer serial port. Do you know some software for Windows (possibly free)? – Alessandro Vitale Mar 11 '13 at 16:34
  • IMO software-only sniffers are not that useful for embedded work, so I can't recommend a product there, nowadays I mostly use a [Logic](http://www.saleae.com/logic) to analyze communications. It's not free but it's a very versatile great little device that I can only recommend. Downside, you need access to the TTL end of the communications (the "inside" of the line drivers), you cannot just clip it on an RS232 link. – fvu Mar 11 '13 at 17:00
0

it should be byte bSend=(byte)0x6; outBuffer.write(bSend);

christian valverde
  • 1