Överföra flyttal via seriell kommunikation

[Korken]

Godagens!

När man ska överföra flyttal via seriell kommunikation, hur brukar ni då göra?
Jag har funderat på att använda mig av vetskapen om talets storlek. Tex om jag vet att talet är 0-1000 så kan jag tex ta mitt flyttal *10^6 för att sedan överföra det som ett 32bit heltal. Då är jag bara en decimal ifrån precisionen i floats men jag tycker att ett bättre sätt borde finnas.
Man kan ju skicka den som rådata, men hur vet jag då att mottagande maskinen kan läsa den?
Det viktiga är att storleken på "saken" som ska lagra floaten inte får vara större än 4 byte.

Har ni några bra tips på detta?

Mvh
Emil

[Icecap]

Jag har aldrig använd flyttal på det vis men jag har ofta överfört med fast decimalkomma. Ska jag alltså överföra 100,0 skickar hag helt enkelt "1000" och mottagaren vet då att enheten är 1/10'del.

[blueint]

I vilken form finns dina flyttal?

Annars är väl en metod att bestämma sig för ett (standardiserat) format och lägga in en identifiering samt flyttalet efteråt.

Tips: http://en.wikipedia.org/wiki/IEEE_754

[Korken]

Flyttalen är på formen "ANSI/IEEE Std 754-2008".
Det är FPUn på min STM32F4 som använder den standarden.

[Swech]

Man kan ju skicka den som rådata, men hur vet jag då att mottagande maskinen kan läsa den?

Tex om jag vet att talet är 0-1000 så kan jag tex ta mitt flyttal *10^6 för att sedan överföra det som ett 32bit heltal. Då är jag bara en decimal ifrån precisionen i floats men jag tycker att ett bättre sätt borde finnas.

Det är väl lika lätt/svårt för mottagande enhet att läsa båda sätt om mottagande inte vet vad som skickas. ?

Det viktiga är att storleken på "saken" som ska lagra floaten inte får vara större än 4 byte

Har mottagande enhet inte mer än 4 bytes ledig plats?
Skall det vara en logg du skall skapa kanske?

Swech

[sodjan]

> Det viktiga är att storleken på "saken" som ska lagra floaten inte får vara större än 4 byte.

Menar du 4 bytes under själva överföringen eller efter mottagandet i andra änden?

Det finns ju ingenting som hindrar att du har ett format på själva "linan"
och ett annat lagringsformat efter mottagandet.

Bestäm dig för ett överföringsformat som är anpassat till (som "rymmer") de
värden som ska överföras. Sedan är det upp till sändare resp mottagare att
göra precis vad de vill (vad som behövs) för att anpassa sig till formatet.

[Korken]

Storleken är just vid överföring, annars räcker inte bandbredden till.
Jag har funderat just på att konvertera till fixed point för att det är enkelt att koda av, men om jag kan skicka det som floats så blir det bättre precision.

[sodjan]

Då har du något fundamentalt designfel.

> men om jag kan skicka det som floats så blir det bättre precision.

Njae, det blir det inte alltid, men det blir större dynamiskt område.
Men precisionen blir i många fall lägre.

[Icecap]

OK, det finns "plats" för 4 bytes i trafiken. Float har ju ett dynamisk område på nånting * 10^+-99 eller så. Om vi utgår ifrån att exponenten kan vara mellan +99 och -99 blir det samlade spannet 199.

Detta span behövs det 8 bit för att beskriva, alltså är själva värdets beskrivning 3 bytes. Precisionen blir alltså 256 gg sämre vid att använda float istället för fast decimalpunkt. Flyttal har alltså, för en given minnesstorlek, sämre noggrannhet än med fast decimalkomma då det ska finnas information om kommats placering också.

Sedan var det frågan om att överföra 4 bytes. Hur har du tänkt dig att synkronisera din överföring? Alltså: hur vet mottagaren att "nu är det ett nyt block som kommer"?

Man kan separera varje block med tid eller specialtecken, det första sänker överföringshastigheten en hel del vid små block, det andra kräver lite bandbredd och ung. 1 byte extra per block.

Så jag håller med sodjan här: fundementalt designfel till att börja med.

[Korken]

sodjan:
Designfel skulle jag inte kalla det. Snarare att få ut så mycket som möjligt på så lite som möjligt.

Icecap:
Precis de som jag står mellan. Fast eller flytande.
Flytande är bra om för att skicka alla typer av tal oberoende vad det innehåller men fixed point har större precision.
Dock så är all precision över 7 decimaler bortkastad då floaten som ska skickas i sig har en precision på 7 decimaler.

Överföringen är redan fixad, det har jag skrivit mycket om i en tidigare tråd men kan inte hitta den just nu.
Men den använder "escaping" då tidssynkning inte fungerar ifall man kopplar på ett BT-modem.

[sodjan]

> Designfel skulle jag inte kalla det.

Självklart är det feltänkt (eller i alla fall inte färdigtänkt ) om du inte
har "plats" för att skicka över dina värden.

Vad är det för intervall/gränsvärden på det som ska överföras?
Vad representerar värderna?

[Korken]

Det ska ska skicka över är mina råa sensordata + mina uppskattade värden.
Det är 3 st 16 bit tal och 10 st floats. Detta göra i 200 Hz för att få ut allt i realtid.
Det + overhead från överföringen är 53 byte per paket dvs 10600 byte/s. Min max banbredd är 11520 byte/s så är nära gränsen (92% av max).
Just därför så får inte floats ta mer än 4 byte styck.

[jesse]

"flyttal" är inget bra sätt att definiera ett värde om man ska optimera lagring/överföring.

Istället behöver man veta:

Inom vilka intervall ska talet befinna sig?

Om du t.ex. mäter temperatur så kanske du inte behöver använda tal som t.ex. 3.1415*10^34, inte heller 1.2374*10^-99.
Om du kan ha samma upplösning i hela spannet duger fix-point bra. Då är upplösningen vid 4 bytes (=32 bitar) väldigt exakt definierad och går inte att optimera mer:

2^32 = 4.29496...*10^9.... upplösningen blir då intervallet delat med 2^32.
Exempel. Intevall 0-1000 ger upplösning 1000/(2^32) = 2.32*10^-7


Vil du ha bättre än så kan du kanske göra TVÅ överföringar med 4 bytes i varje och som då bildar ett 64-bitars tal. Om högsta biten (bit 31) i varje överföring visar om det är höga eller låga delen som överförs har du kvar 62 bitar till data.

[stekern]

float i C är 32 bitar och ieee 754 följs av "allt", så du kan gott bara skicka över dina floats som rådata.

[Andax]

Håller med Stekern. Det enda man bör tänka på är att sändare och mottagare har samma endian, vilket troligtvis är fallet men bäst att checka ändå.