---

Hej alle


Jeg har stillet spørgsmålet tidligere (og tak for alle svarene).


Min løsning fandt jeg ved brug af perl-scriptet:
$ perl -pe 's/(.)/ord($1)."\n"/ges' tri_10kHz_fs00000.txt >
tri_10kHz_fs00000_al.txt


Data blev indlæst ved hjælp af logserial

$ logserial -t /dev/ttyUSB0 -s 38400 -f tri_10kHZ_fs00000.txt


desværre forholder det sig sådan at det signal jeg burde læse ikke ser
ud som det jeg forventede (forventede en trekant)

http://cyberserver.dk/samples_tri_10khz.png


Og jeg mener problemet ligger i enten konverteringen eller et problem
med tegnsæt...

Der er en offset-fejl - toppe burde ligger højere og bunden ligge lavere
(og ikke flyve sjove steder hen).

Jeg er ret sikker på fejlkilden er her og ikke i min hardware! (Trods
jeg selv har udviklet denne)

Måske et C-program er løsningen, men jeg er absolut ingen C-haj og har
hverken styr på det ene eller andet i den retning.

Den nemmeste og simpleste løsning ønskes.

Jeg kan godt sende råfilerne til Jer, men jeg tænker at det nok går galt
med tegnsæt og den slags, så snart vi snakker ovf. over nettet!


Med venlig hilsen
Preben Holm

---

Preben Holm wrote:
>
> http://cyberserver.dk/samples_tri_10khz.png

Det ligner overløb. Jeg tror simpelthen værdierne er for
små eller store til at kunne repræsenteres med otte bits.

--
Kasper Dupont

---

>
> Der er en offset-fejl - toppe burde ligger højere og bunden ligge lavere
> (og ikke flyve sjove steder hen).
>
Nu har jeg kun skråkigget indlæggene, så jeg er ikke helt klar over hvordan,
og hvorfra, data er opsamlet.
Men et dumt spørgsmål: Det har vel ikke noget at gøre med sign bit / ikke
sign bit i indsamlingen / konverteringen?

Det kan man nemlig godt få lidt sjov ud af. Og det bliver ikke nødvendigvis
pænere med C osv.

Mvh
Lars P. Magnussen

---

Preben Holm <64bitNOSPAMNO@mailme.dk> writes:

> desværre forholder det sig sådan at det signal jeg burde læse ikke ser
> ud som det jeg forventede (forventede en trekant)

Du har tilsyneladende problemer med modulo 256. Fylder dine værdier
to bytes i stedet for en?

--
Thorbjørn Ravn Andersen
http://www.unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

>>desværre forholder det sig sådan at det signal jeg burde læse ikke ser
>>ud som det jeg forventede (forventede en trekant)
>
>
> Du har tilsyneladende problemer med modulo 256. Fylder dine værdier
> to bytes i stedet for en?

Der anvendes en 8-bit A/D converter som jeg ikke vil komme nærmere ind på.
Overfører data serialt vha. en usb-serial adapter fra en FPGA, der
ombyttes ikke i signed værdi eller lignende nogle steder.

Mine tegn kunne selvfølgelig godt fylde to byte, men hvis jeg udfører flg.

logserial -t /dev/ttyUSB0 -s 38400 | perl script > output.txt

så går det også galt!


Nogle gode ideer?

---

Preben Holm <64bitNOSPAMNO@mailme.dk> writes:

> Mine tegn kunne selvfølgelig godt fylde to byte, men hvis jeg udfører flg.
>
> logserial -t /dev/ttyUSB0 -s 38400 | perl script > output.txt
>
> så går det også galt!

Det svar forstod jeg ikke rigtigt.

Kan du ikke prøve at lave grafen som du faktisk forventede den i Excel
eller lignende, så der er mulighed for at sammenligne.

--
Thorbjørn Ravn Andersen
http://www.unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:
> Preben Holm <64bitNOSPAMNO@mailme.dk> writes:
>
>
>>Mine tegn kunne selvfølgelig godt fylde to byte, men hvis jeg udfører flg.
>>
>>logserial -t /dev/ttyUSB0 -s 38400 | perl script > output.txt
>>
>>så går det også galt!
>
>
> Det svar forstod jeg ikke rigtigt.


Well, jeg kan ikke rigtig så godt give det nøjagtige, men en trekant a-la


/\ /\
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \/ \

skulle jeg gerne have fået...

jeg hentydede til at tegnsættet måske gav problemerne.. Hvis logserial
gemmer i et tegnsæt og perl bruger et andet kunne det måske give
problemer...


Med venlig hilsen
Preben Holm

---

Preben Holm <64bitNOnoSPAMno@mailme.dk> writes:

> jeg hentydede til at tegnsættet måske gav problemerne.. Hvis logserial
> gemmer i et tegnsæt og perl bruger et andet kunne det måske give
> problemer...

Perlscriptet laver blot tegn om til de tilhørende værdier. Ikke noget
med tegnsæt der.

Ud fra mit beskedne kendskab til den slags kombineret med hvad du
siger, ser det for mig ud som om at de værdier du måler går ud over
den skala som der er angivet som måleinterval, hvorfor at den øverste
byte klippes af. Om det er rigtigt eller ej ved jeg ikke, men du
kunne prøve at justere lidt på følsomheden af måleapparatet for at se
om du kan få noget andet.
--
Thorbjørn Ravn Andersen
http://www.unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

> Perlscriptet laver blot tegn om til de tilhørende værdier. Ikke noget
> med tegnsæt der.
>
> Ud fra mit beskedne kendskab til den slags kombineret med hvad du
> siger, ser det for mig ud som om at de værdier du måler går ud over
> den skala som der er angivet som måleinterval, hvorfor at den øverste
> byte klippes af. Om det er rigtigt eller ej ved jeg ikke, men du
> kunne prøve at justere lidt på følsomheden af måleapparatet for at se
> om du kan få noget andet.

Jeg har selv lavet måleapparatet og der sidder en 8-bit A/D-converter
som bliver trigget på en opadgående flanke. Disse 2000 samplede værdier
sendes over den serielle.

---

Preben Holm wrote:
>
> Der anvendes en 8-bit A/D converter som jeg ikke vil komme nærmere ind på.

Outputtet ligner ikke noget, der kommer fra en 8-bit A/D
konverter. Men måske er der blevet rodet lidt rundt på
bittene. Når jeg ser på tallene på det billede du postede,
så slår det mig, at alle tallene er lige. Da jeg kiggede
lidt nærmere opdagede jeg, at de næsten alle sammen har
den samme værdi i de nederste tre bits. Næsten alle tallene
på listen har formen xxxxx100.

Det er nok ikke nogen tilfældighed, og det er nok heller
ikke fordi de nederste tre bits fra A/D konverteren altid
har givet det samme. Men hvor kommer de tre bits så fra?

--
Kasper Dupont