This discussion is archived
1 2 3 4 5 6 Previous Next 83 Replies Latest reply: Jun 24, 2012 7:28 AM by 938489 Go to original post RSS
  • 75. Re: Trying to capture line feed or carriage return
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    935486 wrote:
    Dear Jschell,
    From my understanding based on the explanation of the hardware person. They ask to look for '$' as the start and '*' ad the end of the string. Thereafter for each complete string send an acknowledgment in this form "@@\r\n". Once the device receive this then it will send the next message. Thats all of my knowledge on the protocol for the device and there is nothing extra. I have tested with my current codes where I start to look first for '$' and start to read the each byte and conver to character later. Finally I look for '*' and then I send the acknowledgement. So since you have experience where in my if statement I could fail please highlight. Thank you in advance for help.
    What do you do if you don't find '*'? What if you don't find '$'? What if you find neither?
    What if you see '*' and '$' but the contents between are not what you expect?
    How often can you expect these messages? If it fails to show up after 1 minute (or one hour) does that mean that the connection is no longer valid?
  • 76. Re: Trying to capture line feed or carriage return
    938489 Newbie
    Currently Being Moderated
    Dear Jschell,
    Good question I never though of this what if the '*' is not found. About the '$' not being found then the whole process of concatenation of the characters wont even start in the first place. The content in between '$' and '*' do varies as it has different values of time and lat long etc. The message expectation depends on the settings of the device and we also have set timeout so then it will broken if it takes too long.
  • 77. Re: Trying to capture line feed or carriage return
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    935486 wrote:
    Dear Jschell,
    Good question I never though of this what if the '*' is not found. About the '$' not being found ...
    The point to my response was that I was pointing that if you do not look at the protocol then you do not know what it is supposed to do and thus you can not anticipate what will happen when it doesn't do that. Nor will you be able to present diagnostic information. For example sometimes it might report an 'error' with useful information but because it doesn't match your form you will never see that.
  • 78. Re: Trying to capture line feed or carriage return
    EJP Guru
    Currently Being Moderated
    Well this continues to be incredible. After nearly three weeks you still know diddly-squat about the protocol. I got bored and found it via Google in +10 seconds:+ NMEA 0183. I particularly recommend you follow the link to Dale dePriest's page.

    Note that the line termination is indeed CRLF, which was your first question nearly three weeks ago.

    Note also that there is no mention anywhere of messages that don't start with a dollar, and that messages don't end with a '*' but with a three-character checksum that starts with '*'.

    I therefore suggest that you are using the wrong serial port parameters so you aren't reading it correctly, hence the apparent junk message which aren't junk at all. (Or else the device is defective, which doesn't square with the working C# code).

    There's no mention of the '@' message but it seems obvious that it is not a response but a request, for an update of where the GPS is at, i.e. @.
  • 79. Re: Trying to capture line feed or carriage return
    938489 Newbie
    Currently Being Moderated
    Dear Ejp,
    The link which you sent is the standard but this guys have change it to make changes according to what I have specified here. That is why also you dont see the mention of '@@\r\n'. In addition I would like to add at last we managed to solve the problem for java they need to add some delay on the device for at least 1 sec then now things work fine. The funny part C# does not require this delay but java do just to share our findings for the rest of the community. Thank you.
  • 80. Re: Trying to capture line feed or carriage return
    EJP Guru
    Currently Being Moderated
    Clearly this bandaid approach does not solve the real problem.
  • 81. Re: Trying to capture line feed or carriage return
    938489 Newbie
    Currently Being Moderated
    Dear Ejp,
    You are suspecting some bugs in their firmware is it? I am also suspecting the same too.
  • 82. Re: Trying to capture line feed or carriage return
    EJP Guru
    Currently Being Moderated
    Whatever explanation you come up with needs to be consistent with your other claim that the C# code works, or else you need to withdraw that claim. A firmware bug cannot possibly meet that criterion. If the C# code doesn't need sleeps, why should the Java code?

    I am suspecting incorrect serial port settings at the interface between the serial I/O and the network actually, as alluded to above. I said nothing about firmware, and I have no idea why you are misattributing your own conclusion to me.
  • 83. Re: Trying to capture line feed or carriage return
    938489 Newbie
    Currently Being Moderated
    Dear Ejp,
    I did not say on the java code I said "add some delay on the device for at least 1 sec". I meant the device need extra 1 sec delay then it works fine with java. So the java code remains as it is no changes to it.
1 2 3 4 5 6 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points