On 18.10.2022 I was flying from Frankfurt to Antalya. Find the data in the graphic attached. The counter (GMC-300E+) was stored under the seat. I didn't care about GPS-data, or hight. My intension was only to produce some reliable data with double byte input to test and refine my parser. Hence, the data where recorded in CPM.
The data where downloaded and parsed whith Matlab. A .bin-file is also existing. If someone (Ullix?) can give me a link where I can upload the .bin I would share the file with other guys who are interested in.
On my flight back home I will put the counter in the suitcase, so that it's transported in the trunck. I will post these data also.
The graphic attached. Currently I have no permanent Internet-access. Might be possible that it takes a while for an answere, if there are any questions or remarks.
It has the expected feature of going to lower CPM from North to South. However, there is this strange "saddle" in the middle, which is unexpected. Do you know which route this flight has taken? Did it do a detour of some kind? Or did it fly at different altitudes? GPS altitude data would be nice :-/
It's disappointing. On my flight back to FRA (08.11.) the counter didn't count. I won't complain, I don't now if the counter stops by itselfe or if I made a mistake (most cases). Anyway it's a pitty. The counter was not dead, the maximum CPM on the display shows 22160. I assume that was the x-raying of the luggage.
Next time I will put the counter in the suitcase again. One direction CPM-mode and the other CPS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As promised, the flight data of FRA-AYT (SXS141, 01/13/23, CPS) and AYT-FRA (SXS140, 02/10/23, CPM), both times the meter was in the luggage compartment. As already posted in the GQ forum there are no major differences between the cabin and luggage compartment.
It was interesting that the incoming suitcases were X-rayed in AYT. Outgoing my luggage was X-rayed two times. First check when entering the airport building and 15 minutes later after check-in.
Incoming luggage is not examined in FRA again, but delivered directly to the belt.
A few words about the data. The binfiles are downloaded with the GQ GMC data viewer. However, the data used in the graphics was downloaded and parsed with Matlab, hence a difference in the length of the data could be possible. I'll attach the full Matlab output also.
Of cause, the data can be used for any further investigations, but if there are interesting points or mistakes I didn't identify, please let me know.
Truly nice data, thank you! I'll put them as examples into the next GeigerLog release.
The bin data were simply read into GeigerLog. GeigerLog treats them as if they were coming directly from a counter. And all were still done with a GMC-300E+ counter?
One can nicely see the decrease in count rate when going south, and the increase when going north. Although, given that both times the counter was in the luggage compartment, the slight difference between them is a bit puzzling.
Different flight altitude? does anybody know whether these flight altitudes back and forth are different?
Cheers, and yes, all data were recorded with GMC-300E+ counter. Feel free to use the data as example or for whatever.
I'll attach the flight data as jpeg and pdf because I'm not sure whether these are available at FlightAware any more or in the future.
Usually I don't use the viewer, but it was very helpful for debugging, some years ago. Anyway I utilized it to download the bin-file because only a view people are using Matlab (or Octave) here, I think.
The reason of the slightly difference might have the reasons:
- position in the trunk (over, between or under other suitcases),
- slightly different route and
- the flight hight was approx. 300 m lower during the flight back (SXS140).
Also the time of flights were different, but in my experience this has no influence the 300+ can resolve.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Erwin55: Thanks. Looks like you have reduced recording to CPM-only, and so could get both flights into the 64k of your counter.
The going-south flight is like textbook-quality - counts going down as they should when you get away from the poles.
Going north is not as clear. I circled in magenta the portion, which would have to be a bit higher up to make it perfect. But then I see in the flight-plan, that the plane lowered flight-level from 11000m down to 10300m. And at lower altitude, the cosmic radiation is lower.
However, this "flight-level" isn't very helpful, as it is defined in barometric pressure, and and converted to altitude in meter. So the true altitude remains unknown. It could have been even lower. Do you remember whether the last 45 min or so, were a bit shaky due to turbulence?
There were a lot of turbulences during that flight and the seat belt sign two or three times on.
I prefere CPM because the GMC-300E+ can buffer only ~16 h. This seems to be enough for a flight lasting 3.5h but if anything goes wrong, the data is overwirtten. Also my wife is not very amused, if the first activity I 'm performing in the hotel after arrival at night, is starting the PC ;)
Anyway, next time, October/November, I'll record the data in CPS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see a need for CPS. All you get are perhaps 2 data points for the X-ray check of luggage instead of 1, which isn't really any more helpful. The travel data need to be averaged to CPM anyway, and these are the ones of interest.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the CPS data can be interesting for the X-Ray check scanner peak, because the peaks are relatively very short and therefore with the CPM data, they are diluted in one or two CPM sums.
EDIT: It would be nice if GQ could use a dynamic mode offering a backup in CPM mode in normal times and if an event is suspected, at that time make it a backup of 60 CPS.
Last edit: Damien 2023-05-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On 18.10.2022 I was flying from Frankfurt to Antalya. Find the data in the graphic attached. The counter (GMC-300E+) was stored under the seat. I didn't care about GPS-data, or hight. My intension was only to produce some reliable data with double byte input to test and refine my parser. Hence, the data where recorded in CPM.
The data where downloaded and parsed whith Matlab. A .bin-file is also existing. If someone (Ullix?) can give me a link where I can upload the .bin I would share the file with other guys who are interested in.
On my flight back home I will put the counter in the suitcase, so that it's transported in the trunck. I will post these data also.
The graphic attached. Currently I have no permanent Internet-access. Might be possible that it takes a while for an answere, if there are any questions or remarks.
Last edit: Erwin55 2022-10-31
Thanks. Could be easily read into GeigerLog.
It has the expected feature of going to lower CPM from North to South. However, there is this strange "saddle" in the middle, which is unexpected. Do you know which route this flight has taken? Did it do a detour of some kind? Or did it fly at different altitudes? GPS altitude data would be nice :-/
To be honest, I can't supply these informations, I didn't recorded it. Our flight was PC5036 18.10.2022 13:35, maybe this helps.
Looks like this route is as straight as it gets:
https://de.flightaware.com/live/flight/PGT5036
Leaves only the flight-altitude. Puzzling.
Last edit: ullix 2022-10-31
It's disappointing. On my flight back to FRA (08.11.) the counter didn't count. I won't complain, I don't now if the counter stops by itselfe or if I made a mistake (most cases). Anyway it's a pitty. The counter was not dead, the maximum CPM on the display shows 22160. I assume that was the x-raying of the luggage.
Next time I will put the counter in the suitcase again. One direction CPM-mode and the other CPS.
Too bad, indeed.
As promised, the flight data of FRA-AYT (SXS141, 01/13/23, CPS) and AYT-FRA (SXS140, 02/10/23, CPM), both times the meter was in the luggage compartment. As already posted in the GQ forum there are no major differences between the cabin and luggage compartment.
It was interesting that the incoming suitcases were X-rayed in AYT. Outgoing my luggage was X-rayed two times. First check when entering the airport building and 15 minutes later after check-in.
Incoming luggage is not examined in FRA again, but delivered directly to the belt.
A few words about the data. The binfiles are downloaded with the GQ GMC data viewer. However, the data used in the graphics was downloaded and parsed with Matlab, hence a difference in the length of the data could be possible. I'll attach the full Matlab output also.
Of cause, the data can be used for any further investigations, but if there are interesting points or mistakes I didn't identify, please let me know.
The flight back to FRA.
Graph FRA-AYT.
Graph AYT-FRA.
Truly nice data, thank you! I'll put them as examples into the next GeigerLog release.
The bin data were simply read into GeigerLog. GeigerLog treats them as if they were coming directly from a counter. And all were still done with a GMC-300E+ counter?
One can nicely see the decrease in count rate when going south, and the increase when going north. Although, given that both times the counter was in the luggage compartment, the slight difference between them is a bit puzzling.
Different flight altitude? does anybody know whether these flight altitudes back and forth are different?
Last edit: ullix 2023-02-14
Cheers, and yes, all data were recorded with GMC-300E+ counter. Feel free to use the data as example or for whatever.
I'll attach the flight data as jpeg and pdf because I'm not sure whether these are available at FlightAware any more or in the future.
Usually I don't use the viewer, but it was very helpful for debugging, some years ago. Anyway I utilized it to download the bin-file because only a view people are using Matlab (or Octave) here, I think.
The reason of the slightly difference might have the reasons:
- position in the trunk (over, between or under other suitcases),
- slightly different route and
- the flight hight was approx. 300 m lower during the flight back (SXS140).
Also the time of flights were different, but in my experience this has no influence the 300+ can resolve.
Route FRA-AYT:
Route AYT-FRA:
Protokoll FRA-AYT:
Protokoll AYT-FRA:
This flight tracking is awesome! I had no idea it is available, thx.
Cheers
Another flight FRA-AYT-FRA for those who are intersted in.
Flightaware protocol only flight back. Sorry.
@Erwin55: Thanks. Looks like you have reduced recording to CPM-only, and so could get both flights into the 64k of your counter.
The going-south flight is like textbook-quality - counts going down as they should when you get away from the poles.
Going north is not as clear. I circled in magenta the portion, which would have to be a bit higher up to make it perfect. But then I see in the flight-plan, that the plane lowered flight-level from 11000m down to 10300m. And at lower altitude, the cosmic radiation is lower.
However, this "flight-level" isn't very helpful, as it is defined in barometric pressure, and and converted to altitude in meter. So the true altitude remains unknown. It could have been even lower. Do you remember whether the last 45 min or so, were a bit shaky due to turbulence?
There were a lot of turbulences during that flight and the seat belt sign two or three times on.
I prefere CPM because the GMC-300E+ can buffer only ~16 h. This seems to be enough for a flight lasting 3.5h but if anything goes wrong, the data is overwirtten. Also my wife is not very amused, if the first activity I 'm performing in the hotel after arrival at night, is starting the PC ;)
Anyway, next time, October/November, I'll record the data in CPS.
I don't see a need for CPS. All you get are perhaps 2 data points for the X-ray check of luggage instead of 1, which isn't really any more helpful. The travel data need to be averaged to CPM anyway, and these are the ones of interest.
the CPS data can be interesting for the X-Ray check scanner peak, because the peaks are relatively very short and therefore with the CPM data, they are diluted in one or two CPM sums.
EDIT: It would be nice if GQ could use a dynamic mode offering a backup in CPM mode in normal times and if an event is suspected, at that time make it a backup of 60 CPS.
Last edit: Damien 2023-05-22