search

jekhokie / raspberry-noaa-v2

V2 of the fantastic Raspberry Pi NOAA setup
GNU General Public License v3.0
533 stars 100 forks source link

epoch_adjusted=$(($PASS_START + 10)) or pad 0 $WXTOIMG_MAP_OFFSET #998

Closed i6cbi closed 2 months ago

i6cbi commented 2 months ago

Hi Mihajlo I think there is already an instruction to adjust the overlay-map

with $SOX "$audio_temporary_storage_directory/noaa_apt.wav" -r 11025 "${RAMFS_AUDIO_BASE}.wav" _pad 0 $WXTOIMG_MAPOFFSET>> $NOAA_LOG 2>&1

it is possible that it will be added ? it wouldn't be better _epoch_adjusted=$(($PASS_START + $WXTOIMG_MAPOFFSET))

log "Bulding pass map" "INFO" -# add 10 seconds to ensure we account for small deviations in timing - being even a second too soon -# can cause an error of "wxmap: warning: could not find matching pass to build overlay map.", while -# going over the start time by a few seconds while still being within the pass timing causes wxmap -# to track back to the start of the pass _epoch_adjusted=$(($PASSSTART + 10))

extra_map_opts= etc etc

map_overlay="${NOAA_HOME}/tmp/map/${FILENAME_BASE}-map.png" -$WXMAP -T "${SAT_NAME}" -H "${TLE_FILE}" -p 0 ${extra_map_opts} -o "${epoch_adjusted}" "$map_overlay" >> "$NOAA_LOG" 2>&1

MihajloPi commented 2 months ago

Hi Silvio, I'm not sure what are you trying to say. Could you please explain it one more time?

I've added 10.5 seconds additional silence in NOAA audio when decoding with WXtoImg due to map overlay issues. This value was found experimentally to be the appropriate, but can additionally be tuned by the end users should they experience further problems. The line epoch_adjusted=$(($PASS_START + 10)) is applicable only for WXtoImg decoding. We manually increase the start time of recording when we pass it to WXtoImg to know that we are receiving the pass, and it automatically subtracts the time and correctly displays the maps. This is an issue with WXtoImg only when pass start time differs in WXtoImg's calculations from our in predict. Let's say a pass starts at 10:50:40, but we calculated with predict that the pass starts at 10:50:39. WXtoImg will think the satellite isn't currently overhead and won't know how to create maps. We artificially add +10 seconds to the start time and make WXtoImg think we started recording at 10:50:50, and it will agree that the satellite is overhead and create maps for the whole duration of the current pass. Since we REALLY started recording at 10:50:40, maps will turn out correct.

I hope I explained well the logic behind this code. If that's been bugging you, you can close this issue. If you still have some doubts, let me know and we'll discuss it further!

i6cbi commented 2 months ago

i'll test !