-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extended Gator Protocol (M558FS) #5069
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's start with some big themes first:
- Please add unit tests for both decoding and encoding
- Fix formatting. For example, variable use our variable name convention. No underscores. Lower camel case names for functions and variables. No shortened words.
- Run gradle check to make sure all checks pass.
I'll do all of this in the upcoming days. |
Added new commit. Gradle Build ran successfully without any StyleCode errors. @abish7643 |
OK, can you please add unit tests and provide the protocol documentation. |
Attaching Protocol Document. The protocol is exactly same as the one found on Protocol page. I'm running the development server locally and using localtonet to forward UDP packets to Gator's predefined port. All functionalities were tested and was working as intended. |
…tor_Protocol_Improved
Added Single Location Reporting Encoder Function |
return buf; | ||
} | ||
|
||
public int[] numToIp(String sim) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function doesn't look right. First of all, the naming of the function and variables is not per our standards. Also, it looks too complicated. It just doesn't make sense. What are you trying to do here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an algorithm mentioned in the Protocol Document. Refer the Appendix section if required.
I have made the variable nomenclature understandable. I copied it from the document, initially even I didn't understand this nomenclature within the document, that's the reason why it ended like this. Now it made sense, so I have modified it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There has to be a better way. This is what it looks like in the decoder:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. The protocol document also have a complicated decoder function. Somehow this is simplified quite extensively,.
I'll look into this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I simplified the encoding function.
Tested it with actual devices.
I have made the required changes as you mentioned, I need to test the device tomorrow since I have changed some parts which you suggested. If there are any modification required, do mention. |
I do need a suggestion. The final one, don't worry. One of the returned data from the device doesn't contain position data, so the last position known data is used. ( Should I set the position valid or not, since technically it's the previous location. |
If you use |
Removed That Line. I'll test all the functionalities tomorrow and will update. |
Works perfect. Tested everything. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're almost there. I've added a few smaller comments, mostly around formatting.
} | ||
|
||
public int[] idToPseudoIPAddress(String deviceID) { | ||
if (deviceID.length() != 11) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So which message is correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tracked it down, the issue lies in the substring creation block. The device ID should be at least 11 to continue with that logic.
public int[] idToPseudoIPAddress(String deviceID) {
if (deviceID.length() != 11) {
return new int[4];
}
int[] ipAddress = new int[4];
for (int i = 0; i < 4; i++) {
ipAddress[i] = Integer.parseInt(deviceID.substring(3 + i * 2, 5 + i * 2));
}
ipAddress[0] = ipAddress[0] % 0x7f;
ipAddress[1] = ipAddress[1] % 0x7f;
ipAddress[2] = ipAddress[2] % 0x7f;
ipAddress[3] = ipAddress[3] % 0x7f;
return ipAddress;
}
According to the protocol document, the device id can be varied in length. The previous developer did assume that the device ID length was 11, that's the reason why the decoder function was simple while my initial encoder function was quite long since I have taken care of the length. Since the decoder creates an ID with a fixed length, there's no point in improving the capability of just the encoder. But to get past Gradle build, I may have to add a conditional check on length there.
So what's your take on this, should I extend the decoder function just like how I initially made the encoder function. Or should I keep it simple like this.
I did configure the tracker with an ID of length 10 rather than 11, and the decoded ID was wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's incorrect, then yes, ideally we should fix it.
String rfidData; | ||
int rfidDataEndIndex = buf.indexOf(buf.readerIndex(), buf.writerIndex(), (byte) 0x0D); | ||
if (rfidDataEndIndex == -1) { | ||
return null; | ||
} | ||
|
||
int length = rfidDataEndIndex - buf.readerIndex(); | ||
rfidData = buf.readCharSequence(length, Charset.defaultCharset()).toString(); | ||
buf.readUnsignedByte(); | ||
|
||
position.set(Position.KEY_DRIVER_UNIQUE_ID, rfidData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need so many variables? Just inline when possible.
String rfidData; | |
int rfidDataEndIndex = buf.indexOf(buf.readerIndex(), buf.writerIndex(), (byte) 0x0D); | |
if (rfidDataEndIndex == -1) { | |
return null; | |
} | |
int length = rfidDataEndIndex - buf.readerIndex(); | |
rfidData = buf.readCharSequence(length, Charset.defaultCharset()).toString(); | |
buf.readUnsignedByte(); | |
position.set(Position.KEY_DRIVER_UNIQUE_ID, rfidData); | |
int rfidEndIndex = buf.indexOf(buf.readerIndex(), buf.writerIndex(), (byte) '\r'); | |
if (rfidEndIndex == -1) { | |
return null; | |
} | |
position.set( | |
Position.KEY_DRIVER_UNIQUE_ID, | |
buf.readCharSequence(rfidEndIndex - buf.readerIndex(), ASCII).toString()); | |
buf.readUnsignedByte(); |
Functionalities Added
Attaching Logs for anyone to do Test Cases