I wanted to test my log book programe and ran it of my 'library' of downloaded logs of problem flights.
Two Mini 3 Pro logs has been giving me a problem. I have just realised what the problem is, both drones have the same Aircraftserial number.

One flight was in Southern Spain, the other, two months earlier, was in Hungary.

I will NOT disclose any greater details on the forum, sorry, not even if the owners ask me. I don't even rememberwho they were and don't know if they are still here, they might even have been from Mavicpilots but I can presumably, if asked, PM the .txt flightlogs to a Mod etc..

I do not have the DAT's.

The camera serial numbers, flightcontroller serial numbers and the guid number (whatever that might be ) RID all differ.

The second drone was activated the day before the problem flight and the DAT number is less than the Dat number of the first drone so they can not be the same drone.

I think I have logs from 36 Mini 3 Pro drones 'on file' so I find it odd that I have such a match.
Just curious, is there an explanation for this?

Could you have accidentally damaged the log file with the wrong serial?

A GUID (also known as a UUID) is a 'unique' ID number.

They are generated randomly and there is no central register so theoretically they can recur, but the probability is very unlikely (I don't remberbthe specific numbers but I read somewhere a while ago that if 100000 UUIDs were generated every second for the next 100000 years then you might see one UUID appear more than once.)

You can read more at http://guid.one/guid

That's the GUID, though, which you say is different anyway (indicating different drone, as you say). How a manufacturer generates serial.numbers, though, is entirely up to them and it's certainly possible that they duplicated numbers.

Probability of you accidentally finding two drones with the same serial number? Pretty slim, I'd say. I'd be tempted to think that your app is getting confused, maybe, as DAFlys says, one of the files is corrupted and your app is failing to read the serial from the corrupted file and instead using the last serial it read successfully.

DAFlys Posted at 5-26 00:32
Could you have accidentally damaged the log file with the wrong serial?

I don't think I could have damaged the log file, I did wonder about that and checked 'then' and I will check again, later.

The logs are not on this computer so I can't check them at the moment but I think I had the original zips of at least the .txts. Those zips would have come from Phantomhelp and I don't know how to 'mess' with zips. But, just in case, prior to writing the opening post I re uploaded the uncompressed .txts to phantomhelp and saw the same data in the then down loaded new csv's.
But ..... if I had damaged the data I would have not expected just two columns and complete columns at that, to be damaged/corrupted.
All serial number columns appear in two places in the csv, under differing headings, I have the impression that the two sets of columns represent separate sets of data and that they are not just duplications of one another.
Occasionally in my own, or other logs, two related columns differ, one may be completely empty of data or just have a few empty cells but that was much more common in Phanton 3 logs than in "Mavic" logs. If there was corruption I would expect partial corruption in those columns and/or more widespread corruption spread throughout the csv but not for an entire column or columns to contain the same flawed data.
Is that a realistic expectation?

There's a weakness in my program and gibberish in a relevant csv cell can screw up the corresponding line in the log book.
When the program encounters such gibberish, instead of outputting the individual csv 's cell content ( gibberish ) the program often outputs the entire corresponding line from the csv in place of that single cell of gibberish data. The program sees the cell as " $0  " which, in Linux, is the shorthand for the entire line in input file.
I get no such screwed up output in the logbook produced when the program processes these csvs.

From my own logs I have seen serial number change 'mid'-column, but always from a wrong serial number to the correct serial number but those incorrect serial number appears in only the first 20 or 30 etc. rows of the csv and they do not extend down the whole column. That 'problem' caused me some confusion early on in my programming. Having just written that has brought to mind a way of handling that in my own logs. From memory the log of the first flight is a thousand+ lines line long and the data was consistent through out each drones' serial number columns and the first flight took place roughly two months before the second drone was activated.

No Original Thought Posted at 5-26 01:11
A GUID (also known as a UUID) is a 'unique' ID number.

They are generated randomly and there is no central register so theoretically they can recur, but the probability is very unlikely (I don't remberbthe specific numbers but I read somewhere a while ago that if 100000 UUIDs were generated every second for the next 100000 years then you might see one UUID appear more than once.)

THANKS !!!
Early on in my programming  I had problems with data being carried over from the processing of one csv to the next, this occurred where the relevant cells in the 'next' csv were empty.
It's another weakness in my programming, the data gathered from the last csv is output to the logbook ONLY when the program starts to process the next csv. This also means I have to have a permanent fake log csv at the end of the folder that contains the logs csv's otherwise I would never get the last log written to my log book.
To fix that "carry over", lines of code were added to the program that zero all data storage variables and counters BEFORE the program starts to examine the data in the 'next' csv, e.g.
" if (FNR == 1) { variable1=0 ;variable2=0 ;vari.......} " .
It still occasionally catches me out if I develop an interest in a 'new' column of data from the csv but serial number storage variables have long since been zeroed when FNR =1, they were amongst the first things I looked at.
"FNR" being Linux short hand for the first line of input from a new file.

Hi there. Thank you for reaching out, Sean. Can you please provide us the serial numbers via PM with the additional information so we can check it further and provide you with an accurate resolution? Please note that each drone has its own unique serial number and we haven't received any inquiries about duplicate serial numbers. We will wait for your response via PM. Thank you for your cooperation, Sean.

DJI Paladin Posted at 5-26 23:29
Hi there. Thank you for reaching out, Sean. Can you please provide us the serial numbers via PM with the additional information so we can check it further and provide you with an accurate resolution? Please note that each drone has its own unique serial number and we haven't received any inquiries about duplicate serial numbers. We will wait for your response via PM. Thank you for your cooperation, Sean.

Will do, thanks.

Hi Paladin, PM sent, thanks.

Sean-bumble-bee Posted at 5-28 11:53
Hi Paladin, PM sent, thanks.

Thank you, Sean. We already responded. We will discuss this via PM, kindly please check your inbox. Have a nice day ahead!

DJI Paladin Posted at 5-28 20:53
Thank you, Sean. We already responded. We will discuss this via PM, kindly please check your inbox. Have a nice day ahead!

Thanks for the very quick responce.
Whoops, I just noticed one of the 'logs' I sent you was the wrong one, I must have been tired or something. I will have to dig the correct log out later, it doesn't appear to be on this device.

Nabízí se logické vysvětlení. Dron byl odeslán k opravě. Původní majitel dostal „nový“ dron. Původní dron byl po opravě odeslán jinému majiteli jako náhradní.
Tak, jak funguje program „refresh care“, těchto případů bude postupně přibývat.
Thus, two owners can have records with the same SN at different times.

Mirek_62 Posted at 5-28 23:30
Nabízí se logické vysvětlení. Dron byl odeslán k opravě. Původní majitel dostal „nový“ dron. Původní dron byl po opravě odeslán jinému majiteli jako náhradní.
Tak, jak funguje program „refresh care“, těchto případů bude postupně přibývat.
Thus, two owners can have records with the same SN at different times.

Can you type that in English please? Google translate can't make sense of it.

Sean-bumble-bee Posted at 5-28 22:12
Thanks for the very quick responce.
Whoops, I just noticed one of the 'logs' I sent you was the wrong one, I must have been tired or something. I will have to dig the correct log out later, it doesn't appear to be on this device.

You're welcome, Sean. Please let us know via PM once you find the said information. Thank you for your valued support.

Sean-bumble-bee Posted at 5-28 23:56
Can you type that in English please? Google translate can't make sense of it.

I offer up a logical explanation. The drone has been sent in for repair. The original owner got a "new" drone. The original drone was sent to another owner as a replacement after repair.
The way the "refresh care" program works, these cases will gradually increase.
So two owners may have records with the same SN at different times.

Thanks , I will have a look at the logs of the first flight to see if the drone was lost or landed etc.

Mirek_62 Posted at 5-29 05:48
I offer up a logical explanation. The drone has been sent in for repair. The original owner got a "new" drone. The original drone was sent to another owner as a replacement after repair.
The way the "refresh care" program works, these cases will gradually increase.
So two owners may have records with the same SN at different times.

You might have a point, due to similarities is a group of serial numbers (four-serial-numbers i.e the serial numbers of five-drones, differ by one character) I got the dates mixed up.

What I considered to be the second flight was in fact the first flight and I suspect the first drone was returned, so the second drone, 2 months later, may have used whatever carries the common serial number.

DJI Paladin Posted at 5-28 20:53
Thank you, Sean. We already responded. We will discuss this via PM, kindly please check your inbox. Have a nice day ahead!

PM sent, thanks.

Sean-bumble-bee Posted at 5-29 09:55
PM sent, thanks.

Thank you, Sean. We responded to your inquiry in PM. Thank you for your continued support.

Thanks Paladin.

Sean-bumble-bee Posted at 6-1 03:32
Thanks Paladin.

You're welcome, Sean. Have a nice day ahead.