CRC mismatch on some target ID + other bugs

1- Some target ID's are displayed as crc mismatch on the log console (with Decode after Encoding). some examples (there is a lot more): CC1B 456b 0008 They seem to work, and decoded by radio.

but after clicking back and forth PTTID and SelCall, the produced MDC stops working I have found that apart restarting the app, i can restore valid MDC by creating a valid 2 packet in advanced mode, sending this, at first, makes a valid MDC but with the old (previous non working try) targetID, with the new advanced packet source ID. Encoding again, this time made this advanced mode 2packet call, with correct source and target ID's decoded.

I'm using the Iphone app "Radio ID" from Matthew Kaufman to decode these so i'm not sure if the switch of ID's happen in the decode app, or MDCTool encoder.

2- Single Packet button sends double packet encodings starting from the first time the "double packet" button is pressed...

If we send a call with the "Tool Ptt ID" or "Radio Check", a 1 packet call is generated. But as soon as we press a 2 packet button like "SelCall" or "Call Alert/Page" , all subsequent single packet are generated with a second packet attached to it (MDC is longer)

we need to close and restart the app to be able to make a 1 packet call again ( shorter )

3- Behaviour seen (may be related to the above):

Created packets aren't decoded by devices, but become valid after using a "SelCall" with a target ID that does not produce a crc mismatch in the log, then trying again the problematic packet.
After prolonged use of the program, randomly enters a state where all encoded calls are doubled ( we hear 2 complete distinct sequences backtoback ) and we need to restart the program to stop this. (Although the encoded double MDC seems to be decodable as devices react to it )

I'm working with non-motorola MDC devices at the moment so if someone needs more info or tests i'm available.

gatekeep / MDCTool

CRC mismatch on some target ID + other bugs #1