hwOS Header Doku falsch?
Posted: Wednesday 25. April 2018, 17:54
Hallo,
ich hab gestern angefangen eine kleine C# Library zu schreiben welche mit dem OSTC sprechen kann, dabei ist mir beim Parsen der langen Dive Header aufgefallen, Byte 17/18 (Max. Depth in mbar) mit der zugehörigen Note 1 die Note nicht ganz hinkommt.
In Note 1 steht:
[quote="Note 1"]
Depth in meters = Depth in mbar*g0/1000 (g0=9,80665m/s2)
[/quote]
Jedoch muss man g0 = 10 und nicht 9,80665m/s2 verwenden um den selben Wert wie im OSTC Logbuch zu erhalten.. Das macht auch Sinn, wenn man in den Firmware Source schaut:
In ghostwriter.asm wird auf Zeile 519 ff. folgendes getan:
[quote]
[pre]
btfss FLAG_apnoe_mode ; Store apnoe max or normal max (Which is only max from the last descent)
bra end_dive1 ; Store normal depth
movff apnoe_max_pressure+0,lo
movff apnoe_max_pressure+1,hi
call adjust_depth_with_salinity ; computes salinity setting into lo:hi [mbar]
movff lo,apnoe_max_pressure+0
movff hi,apnoe_max_pressure+1
movf apnoe_max_pressure+0,W ; Max. depth
rcall ghostwrite_byte_header ; WREG -> Header in ext. flash
movf apnoe_max_pressure+1,W
rcall ghostwrite_byte_header ; WREG -> Header in ext. flash
bra end_dive2 ; skip normal max. depth
end_dive1:
movff max_pressure+0,lo
movff max_pressure+1,hi
call adjust_depth_with_salinity ; computes salinity setting into lo:hi [mbar]
movff lo,max_pressure+0
movff hi,max_pressure+1
movff max_pressure+0,WREG ; Max. depth
rcall ghostwrite_byte_header ; WREG -> Header in ext. flash
movff max_pressure+1,WREG
rcall ghostwrite_byte_header ; WREG -> Header in ext. flash
[/pre]
[/quote]
adjust_depth_with_salinity (tft_outputs.asm:4374) rechnet aber bereits 0,98 als Faktor mit ein:
[quote]
[pre]
;=============================================================================
global adjust_depth_with_salinity
global adjust_depth_with_salinity_log
adjust_depth_with_salinity: ; computes salinity setting into lo:hi [mbar]
btfsc simulatormode_active ; Do not apply salinity in simulator mode
return
movff opt_salinity,WREG ; 0-5% opt_salinity is moved to WREG
adjust_depth_with_salinity_log: ; computes salinity setting (FROM WREG!) into lo:hi [mbar]
addlw d'100' ; 1.00kg/l add 100 to WREG
movwf up ; W is moved to a register (up)
movlw d'105' ; 105% ? 105 is written into W
cpfslt up ; Salinity higher limit, COMPARE up register with W
return ; Out of limit, do not adjust lo:hi
movlw d'99' ; 99% ?
cpfsgt up ; Salinity lower limit
return ; Out of limit, do not adjust lo:hi
movff lo,xA+0 ; lo is moved to xA+0 (Copies current pressure in mBar to register xA)
movff hi,xA+1 ; hi is moved to xA+1
movlw d'102' ; 0,98bar/10m 102 is written into W
movwf xB+0 ; move W into register xB
clrf xB+1 ; clear regsiter xB+1
call mult16x16 ; xA*xB=xC (lo:hi * 100) currentpressure mBar is multiplied by 102
movff up,xB+0 ; Salinity
clrf xB+1
call div32x16 ; xC:4 / xB:2 = xC+3:xC+2 with xC+1:xC+0 as remainder current pressure * 102 is divided by salinity% + 100
movff xC+0,lo
movff xC+1,hi ; restore lo and hi with updated value
return
;=============================================================================
[/pre]
[/quote]
Die Note 1, im hwos_interface.odt ist also etwas verwirrend!
Ich fände es an sich gut, wenn "Max. Depth in mbar" nicht in schon verechneten Milibar angegeben wäre sondern da der tatsächlich Messwert enthalten wäre.. Die Erdbeschleunigung + die Salinity würde man dann on demand beim darstellen dazurechnen, das wäre verständlicher..
Wenn man es übertreiben möchte, könnte man auch noch eine unterschiedliche Erdbeschleunigung je nach geographischer Breite und die Temperatur der einzelnen Wasserschichten der Wassersäule über dem Taucher näherungsweise aus den Temperaturprofildaten mit in Betracht ziehen, da ja Wasser je nach Temperatur unterschiedliche Dichte hat.
Jeder OSTC hat doch eh einen in der ein oder anderen Form einen 3D Beschleunigungssensor verbaut?! Evtl. könnte man auch diese Daten verwenden um die aktuelle Erdbeschleunigung zu messen, die Dinger sind ja recht genau! Wenn die Summe > 2 sec in einem bestimmten Band stabil bleibt, kann man ja gut davon ausgehen, dass das die aktuelle Erdbeschleunigung ist. (Falschirmspringen und Parabelflug mit Tauchausrüstung mal ausgeschlossen)
Bike-shedding: adjust_depth_with_salinity ist vielleicht auch in tft_outputs.asm nicht wirklich gut aufgehoben, wenn sie später aus dem ghostwriter.asm aufgerufen wird..
ich hab gestern angefangen eine kleine C# Library zu schreiben welche mit dem OSTC sprechen kann, dabei ist mir beim Parsen der langen Dive Header aufgefallen, Byte 17/18 (Max. Depth in mbar) mit der zugehörigen Note 1 die Note nicht ganz hinkommt.
In Note 1 steht:
[quote="Note 1"]
Depth in meters = Depth in mbar*g0/1000 (g0=9,80665m/s2)
[/quote]
Jedoch muss man g0 = 10 und nicht 9,80665m/s2 verwenden um den selben Wert wie im OSTC Logbuch zu erhalten.. Das macht auch Sinn, wenn man in den Firmware Source schaut:
In ghostwriter.asm wird auf Zeile 519 ff. folgendes getan:
[quote]
[pre]
btfss FLAG_apnoe_mode ; Store apnoe max or normal max (Which is only max from the last descent)
bra end_dive1 ; Store normal depth
movff apnoe_max_pressure+0,lo
movff apnoe_max_pressure+1,hi
call adjust_depth_with_salinity ; computes salinity setting into lo:hi [mbar]
movff lo,apnoe_max_pressure+0
movff hi,apnoe_max_pressure+1
movf apnoe_max_pressure+0,W ; Max. depth
rcall ghostwrite_byte_header ; WREG -> Header in ext. flash
movf apnoe_max_pressure+1,W
rcall ghostwrite_byte_header ; WREG -> Header in ext. flash
bra end_dive2 ; skip normal max. depth
end_dive1:
movff max_pressure+0,lo
movff max_pressure+1,hi
call adjust_depth_with_salinity ; computes salinity setting into lo:hi [mbar]
movff lo,max_pressure+0
movff hi,max_pressure+1
movff max_pressure+0,WREG ; Max. depth
rcall ghostwrite_byte_header ; WREG -> Header in ext. flash
movff max_pressure+1,WREG
rcall ghostwrite_byte_header ; WREG -> Header in ext. flash
[/pre]
[/quote]
adjust_depth_with_salinity (tft_outputs.asm:4374) rechnet aber bereits 0,98 als Faktor mit ein:
[quote]
[pre]
;=============================================================================
global adjust_depth_with_salinity
global adjust_depth_with_salinity_log
adjust_depth_with_salinity: ; computes salinity setting into lo:hi [mbar]
btfsc simulatormode_active ; Do not apply salinity in simulator mode
return
movff opt_salinity,WREG ; 0-5% opt_salinity is moved to WREG
adjust_depth_with_salinity_log: ; computes salinity setting (FROM WREG!) into lo:hi [mbar]
addlw d'100' ; 1.00kg/l add 100 to WREG
movwf up ; W is moved to a register (up)
movlw d'105' ; 105% ? 105 is written into W
cpfslt up ; Salinity higher limit, COMPARE up register with W
return ; Out of limit, do not adjust lo:hi
movlw d'99' ; 99% ?
cpfsgt up ; Salinity lower limit
return ; Out of limit, do not adjust lo:hi
movff lo,xA+0 ; lo is moved to xA+0 (Copies current pressure in mBar to register xA)
movff hi,xA+1 ; hi is moved to xA+1
movlw d'102' ; 0,98bar/10m 102 is written into W
movwf xB+0 ; move W into register xB
clrf xB+1 ; clear regsiter xB+1
call mult16x16 ; xA*xB=xC (lo:hi * 100) currentpressure mBar is multiplied by 102
movff up,xB+0 ; Salinity
clrf xB+1
call div32x16 ; xC:4 / xB:2 = xC+3:xC+2 with xC+1:xC+0 as remainder current pressure * 102 is divided by salinity% + 100
movff xC+0,lo
movff xC+1,hi ; restore lo and hi with updated value
return
;=============================================================================
[/pre]
[/quote]
Die Note 1, im hwos_interface.odt ist also etwas verwirrend!
Ich fände es an sich gut, wenn "Max. Depth in mbar" nicht in schon verechneten Milibar angegeben wäre sondern da der tatsächlich Messwert enthalten wäre.. Die Erdbeschleunigung + die Salinity würde man dann on demand beim darstellen dazurechnen, das wäre verständlicher..
Wenn man es übertreiben möchte, könnte man auch noch eine unterschiedliche Erdbeschleunigung je nach geographischer Breite und die Temperatur der einzelnen Wasserschichten der Wassersäule über dem Taucher näherungsweise aus den Temperaturprofildaten mit in Betracht ziehen, da ja Wasser je nach Temperatur unterschiedliche Dichte hat.
Jeder OSTC hat doch eh einen in der ein oder anderen Form einen 3D Beschleunigungssensor verbaut?! Evtl. könnte man auch diese Daten verwenden um die aktuelle Erdbeschleunigung zu messen, die Dinger sind ja recht genau! Wenn die Summe > 2 sec in einem bestimmten Band stabil bleibt, kann man ja gut davon ausgehen, dass das die aktuelle Erdbeschleunigung ist. (Falschirmspringen und Parabelflug mit Tauchausrüstung mal ausgeschlossen)
Bike-shedding: adjust_depth_with_salinity ist vielleicht auch in tft_outputs.asm nicht wirklich gut aufgehoben, wenn sie später aus dem ghostwriter.asm aufgerufen wird..