apim-asbuilt-decode
apim-asbuilt-decode copied to clipboard
Great Work, not sure how to contact you, i have a question
Hey Great work with this tool, as you are already aware we have made a web viewer for this.
All credit is given to you :)
Anyway my question,
It seems blocks 5 and 7 of SYNC 3 use a different command line output, is there a reason for this? currently the regex we use break on these sections because of it.
And just for clarification on how it currently works
You can upload files here
https://cyanlabs.net/fhub/sync3-apim-asbuilt-db/
And will be redirected to something like https://cyanlabs.net/fhub/apim-asbuilt-decoder/?filename=scott_mark_smax_nav_ireland_1.abt
However if on SYNC 3 files you go to Block 5 or 7 it shows nothing as the regex doesn't parse it correctly because the formatting is different, unsure if there is a obvious reason for the formatting being different on the CLI output here?
Nice to see it being used!
Anyway: The reason is that the values are calculated instead of lookup tables, but it's not too difficult to change it to something parsable.
The block 5/7 values are ([binary value] + (offset in loop table)) * (multiplier in lookup table) with a "unit" added to this.
I copied the idea from what the Sync 3 module does and the format is different as the parsing was different when I made it.
There is no real reason to not change it to something else. One way to make it work is by putting all 65536 values in there but that would be a bit much. Any suggestions for making it more uniform?
You can also PM me on your own forum as I actually registered there was well (same name).
Anyway: The reason is that the values are calculated instead of lookup tables, but it's not too difficult to change it to something parsable.
The block 5/7 values are ([binary value] + (offset in loop table)) * (multiplier in lookup table) with a "unit" added to this.
I copied the idea from what the Sync 3 module does and the format is different as the parsing was different when I made it.
There is no real reason to not change it to something else. One way to make it work is by putting all 65536 values in there but that would be a bit much. Any suggestions for making it more uniform?
Ah right I see, that makes sense, no immediate suggestions come to mine but i'll have a think and let you know :)
Like you said adding 65536 values is a bit much so i would agree that a better idea should probably be implemented.
You can also PM me on your own forum as I actually registered there was well (same name).
Oh yes that's right, i remember seeing you on their now 😆
I also noticed the values are rounded off to one digit so I'll fix that as well. Also the actual value is (binary * multipler) + offset but for your purposes that doesn't really matter.