Onkohan täällä joku RF-elektroniikkaguru? Minulla on kaksi RF-moduulia (lähetin-vastaanotinta), joilla voi esimerkiksi ohjata Nexa-pistorasioita. Molemmat toimivat ongelmitta vanhassa Raspberry Pi:ssä. Jostain syystä sama RF-moduuli kytkettynä Raspberry Pi Picoon ei saa aikaan pistorasioissa reaktiota, vaikka testeissä kummallakin alustalla RF-moduulit antavat ihan samanlaiset tulokset (datan ja signaalin voimakkuuden) oikealta kaukosäätimeltä ja saavat viestit myös toisiltaan yhtä hyvin (tai huonosti; en ole panostanut OOK:n vastaanottoasetuksiin), eli kaiken järjen mukaan mitään eroa ei pitäisi olla.
Tietenkin olen testannut myös vaihtaa RF-moduulit päittäin, mutta tulos pysyy samana, eli kaikki näyttää toimivan paitsi Picon lähetys pistorasialle. Olen testannut kaukaa ja läheltä ja myös ihan sentin päästä pistorasiasta. Sen sijaan alkuperäinen Raspberry Pi saa viestin perille yleensä koko asuntoon myös ovet suljettuina.
RF-moduulit perustuvat CC110L-piiriin ja niitä ohjataan SPI:llä. Koodit olen tehnyt Pythonilla, sama koodi toimii molemmissa laitteissa, vain SPI-kirjasto ja pari järjestelmäfunktiota vaihtuu alustan mukaan. Nexa-pistorasioiden radioprotokolla on yksinkertainen OOK eli On–off-keying 433,92 MHz:n taajuudella ja nopeudella 5587 bps. Pistorasian komento on tulkittavissa 408 bitin mittaiseksi, ykkösbittejä on vain 2/12, ja komento lähetetään aina muutaman kerran peräkkäin.
Mistä ihmeestä voisin etsiä vikaa?
Itse luultavassti koittaisin logiikka-analysaattorilla verrata toimivan ja ei toimivan ympäristön SPI-liikennettä ja katsoa eroja. Saattaa olla että esim. SPI-kirjasto toimii eri lailla ja joku bitti meneekin eri järjestyksessä tms.
Kirjoitit että data on kummallakin lähettimellä ihan sama. Onko se siis katsottu radiotieltä? Jos signaalinvoimakkuus ja data ovat samat niin sitten jäljelle jää taajuus, modulointi ja symbolinopeus. Mutta tosiaan lähettimelle menevän SPI-liikennöinnin erothan ne RF-lähetteen erot aiheuttaa, kun kerran olet ristiin lähettimiä kokeillut.
No niin. Syyksi paljastui tuo SPI mutta hieman eri mielessä: Matalilla kellotaajuuksilla Picon SPI aiheuttaa radio-osastolle jotain häikkää niin, että bittejä kääntyy (nimenomaan radiosignaalista). Tietyillä kellotaajuuksilla RF-moduuli jopa alkaa ”vastaanottaa” itsekseen jotain toistuvaa bittikuviota kynnyksen ylittävällä voimakkuudella. Aiemmassa testissäni jotenkin sattumalta ei osunut virheitä siihen dataan, jonka tarkastin kunnolla, ja muualla oli niin vähän virheitä, että en huomannut niitä silmämääräisesti.
Ongelma poistui, kun nostin SPI:n kellotaajuuden 250 kHz:iin. Ilmeisesti Linuxissa on jokin sellainen minimitaajuus, että ongelma ei tule siinä esiin.
CC110L on niin mutkikas, että varsinaiset SPI:n datavirheet huomaisi luultavasti jo asetuksia laittaessa. Ainakin MicroPythonin SPI-luokka on osoittautunut tähän mennessä käyttökelvottomaksi, mutta SoftSPI onneksi toimii.
Joo eli logiikka-analysaattorilla SPI-liikenteen eroja katsomalla näki (tai olisi nähnyt) heti, että lähetysnopeus oli pienempi.
Joillakin SPI-laitteilla voi käyttää miten pientä taajuutta tahansa mutta joillakin pienet taajuudet ei toimi tai ne "timeouttaavat" jos moniosaisen komentoketjun komennot tulee liian hitaasti.
Grez kirjoitti:
Joo eli logiikka-analysaattorilla SPI-liikenteen eroja katsomalla näki (tai olisi nähnyt) heti, että lähetysnopeus oli pienempi.
Kyllä vain. Tosin itse en ole viitsinyt säätää RPi:tä tai Picoa logiikka-analysaattoriksi eikä ole siihen muutakaan valmista laitetta.
Grez kirjoitti:
Joillakin SPI-laitteilla voi käyttää miten pientä taajuutta tahansa mutta joillakin pienet taajuudet ei toimi
CC110L toimii kyllä SPI:n puolesta jopa 250 Hz:n taajuudella (mutta 200 Hz ei enää toimi ainakaan minun koodillani). Silloin tietysti lähettimen FIFO pitää täyttää ennen lähetyksen alkua, ettei lähetys katkea. SPI toimii myös lähetyksen aikana ihan oikein, esimerkiksi FIFO:n täyttöastetta voi seurata ja lähetyksen voi lopettaa. Testasin vielä, että kun TX-FIFO täytetään valmiiksi (vaikka sitten 250 Hz:lla :D) ja lähetyksen aikana ei enää viestitä SPI:llä mitään, lähetys toimii oikein. Eli jotenkin juuri SPI:n aktiivisuus matalalla kellotaajuudella aiheuttaa häiriöt RF-puolelle. Varmaan tähän on jokin elektroninen syy, jota ei ole katsottu tarpeelliseksi mainita spekseissä (joissa on annettu SPI:lle vain maksiminopeus).
Metabolix kirjoitti:
CC110L toimii kyllä SPI:n puolesta jopa 250 Hz:n taajuudella (mutta 200 Hz ei enää toimi ainakaan minun koodillani).
Luulen että tässä viimeisessä viestissäsi puuttuu kilot hertsien edeltä.
Mutta tuo minkä mainitsit, että datalehdessä ei mainita kaikkea on näiden elektroniikkarekkuloiden kanssa todella yleistä, vaikka datalehdet on usein satoja sivuja pitkiä. Ajattelisin että kyse ei ole edes siitä että tietoja tarkoituksella jätettäisiin kertomatta, vaan kyseessä voi olla ihan bugi tai käyttötapaus, jota suunnittelijat ei ole tulleet ajatelleeksi.
Joskus datalehtiä myös päivitetään kun kentältä tulee tietoa bugeista. Tosin tuo on 2011 alunperin tehty datalehti ja viimeisin revision 2016, joten luulisi olevan jo pahimmat bugit huomioituna.
Grez kirjoitti:
Metabolix kirjoitti:
CC110L toimii kyllä SPI:n puolesta jopa 250 Hz:n taajuudella (mutta 200 Hz ei enää toimi ainakaan minun koodillani).
Luulen että tässä viimeisessä viestissäsi puuttuu kilot hertsien edeltä.
Vaan ei puutu. :) Ruudulta näkee, kun yksinkertaisesti rekisterien 00-2f dumppaus kestää useamman sekunnin.
Epäilemäsi 250 kHz puolestaan toimii ilman RF-häiriöitä, sehän on jo kohtuullinen nopeus.
Alkuperäinen SPI-nopeuteni oli noin 100 kHz, ja radiosignaalin häiriöitä näyttää tulevan ainakin 170 kHz:n nopeuksiin asti. Ja kuten edellä sanoin, SPI toimii täysin moitteettomasti ja ongelmat ovat vain radiosignaalissa ja vain silloin, kun SPI on aktiivinen samaan aikaan radiosignaalin kanssa.
Grez kirjoitti:
Mutta tuo minkä mainitsit, että datalehdessä ei mainita kaikkea on näiden elektroniikkarekkuloiden kanssa todella yleistä, vaikka datalehdet on usein satoja sivuja pitkiä. Ajattelisin että kyse ei ole edes siitä että tietoja tarkoituksella jätettäisiin kertomatta, vaan kyseessä voi olla ihan bugi tai käyttötapaus, jota suunnittelijat ei ole tulleet ajatelleeksi.
Joo. Tässä nimenomaisessa ärsyttää se, että moniin asetuksiin ei ole mitään selitystä käytöstä tai edes merkitysestä, vaan sanotaan, että laita tähän meidän suunnittelusoftan antama luku. Kyseinen softa tietysti toimii vain Windowsissa.
No jopas. En kyllä millään olisi arvannut, että jokin laite oletuksena käyttää SPI-väylää alle 250Hz nopeudella.
Siirryin pistorasia-asiasta eteenpäin, tarkempaan tiedonsiirtoon ja 2-FSK-modulaatioon. Valitettavasti ongelma ei ole sittenkään ratkennut: vaikka SPI-nopeus olisi esimerkiksi 1 MHz tai 6 MHz, juuri Picon SPI aiheuttaa häiriöitä radioliikenteeseen.
Eli selvennyksenä vielä ongelma ja sen purkkaratkaisu:
spi_fill_cc110l_tx_queue() # toimii
spi_init_rf_transmission() # toimii
if purkkaratkaisu:
sleep(8 * tx_size / bps) # toimii: SPI on tauolla lähetyksen ajan
else:
while not spi_tx_done(): # aiheuttaa häiriöitä radioliikenteeseen
continuePurkkaratkaisun eli SPI-tauon ongelma on se, että yli 64-tavuisia viestejä ei voi lähettää, kun ei pääse täydentämään jonoa lähetyksen aikana.
Grez kirjoitti:
No jopas. En kyllä millään olisi arvannut, että jokin laite oletuksena käyttää SPI-väylää alle 250Hz nopeudella.
No ei varmaan käytäkään, vaan testasin sitä ihan vain esimerkiksi, kun epäilit hidasta SPI:tä ongelmaksi. Kuten edellä totesin, ongelmani ei liity SPI:n toimivuuteen vaan radiosignaalin häiriöön.
Grez kirjoitti:
testasin sitä ihan vain esimerkiksi, kun epäilit hidasta SPI:tä ongelmaksi.
Aivan. Hyvä testi. Kirjoitit että ongelma poistui, kun kasvatit nopeutta, joten sen takia se vaikutti mahdolliselta ongelmalta. Mutta kyse ilmeisesti olikin vain ajoituksellisesta sivuvaikutuksesta.
Olet Metabolix todella lahjakas henkilö ja itseohjautuva! Päihität jopa monet alaan suuntautuneet tietoliikennetekniikan kandidaatit. Tämän vuoksi haluan tarjota sinulle hieman kurssimateriaalia harrastuksesi tueksi. Oheisen linkin alta löydät hieman kurssimateriaalia tietoliikennetekniikan kurssilta (vuodelta kypärä ja miekka): https://www.dropbox.com/sh/g88sdgei1e0puir/
On ilo nähdä ihmisiä, jotka kykenevät itseohjaamaan itseään niin paljon, että alaan liittyvää pohjakoulutusta ei välttämättä edes tarvitse. Sanoisin, että päihittäisit n. 80 % kanssakilpailijoistasi työhaussa ilman pohjakoulusta IT-alalta. Tämä on jo itsessään ironista kyllä, mutta samalla sinun tapauksessasi harvinaisen totta :D
mpni kirjoitti:
Oheisen linkin alta löydät hieman kurssimateriaalia tietoliikennetekniikan kurssilta (vuodelta kypärä ja miekka): – –
Kiitos materiaaleista, mutta tämänhetkisillä tiedoilla näyttää, että ne eivät suoranaisesti liity ongelmaan. En ole rakentamassa omaa RF-moduulia, ja radioliikenne on täysin toimivaksi todettu, kun SPI:n häiriön saa väistettyä.
Grez kirjoitti:
Kirjoitit että ongelma poistui, kun kasvatit nopeutta, joten sen takia se vaikutti mahdolliselta ongelmalta. Mutta kyse ilmeisesti olikin vain ajoituksellisesta sivuvaikutuksesta.
Mitähän tarkoitat tässä ajoituksellisella sivuvaikutuksella.
Selvästikin Picon SPI aiheuttaa joka tapauksessa häiriöitä ja ongelma vain korostuu alemmilla SPI:n nopeuksilla. Häiriön vaikutus radiosignaaliin riippuu tietysti tilanteesta, eli tuo Nexa-protokollan 6 kbps OOK-moduloitu viesti selviytyy jostain mikrosekunnin häiriöistä mutta 200 kbps signaali ei selviydy.
Keksin vielä yhden testin: CC110L:llä pystyy lähettämään jatkuvasti preamblea (0101...) ilman enempää SPI-syötettä. Tämän jälkeen voi testata SPI:tä tai yksittäisiä pinnejä, miten huvittaa. Tässä paljastuu, että häiriö tulee, jos CS (chip select) tai MOSI on nollassa.
Häiriö ei tule siis edes pinnien tilan vaihdosta vaan siitä, että CS tai MOSI on nollassa. Voisiko GPIO:n kautta tuleva ”nolla” olla niin häiriöinen, että se aiheuttaisi tällaista, ja mikä tähän sitten olisi oikea ratkaisu? Jossain epäiltiin tietokoneen USB:tä huonon nollan syyksi, mutta tilanne ei muuttunut erillisellä virtalähteellä. Testasin tasapuolisuuden vuoksi myös virran ja maan syöttöä GPIO-pinnien kautta, mutta tulos oli sama.
Metabolix kirjoitti:
Mitähän tarkoitat tässä ajoituksellisella sivuvaikutuksella.
Sitä, että muutos ajoituksessa vaikutti RF-lähetteeseen. Eli esimerkiksi tuo havaitsemasi CS tai MOSIN olo nollassa aiheuttaa häiriön (sivuvaikutuksen) ja kun tämä ajoittuu hyötylähetteeseen, niin silloin tulee ongelma mutta kun tämä ajoittuu hetkeen kun ei lähetetä, niin ei ole ongelmaa.
Tämä menee nyt ihan arvailuksi tietämättä piirin tarkkaa kytkentää ja piirilevyn rakennetta ja koska en ole RF-asiantuntija, mutta tulee mieleen että ko. linjat esim. kapasitiivisesti vaikuttaisivat (tosin silloinhan kai nimenomaan muutos vaikuttaisi) piirilevyllä joko lähetteeseen tai kellotaajuuteen.
Workaround voisi olla varmistaa, että kumpikaan pinneistä ei ole nollassa hyötylähetteen aikana.
Grez kirjoitti:
Tämä menee nyt ihan arvailuksi tietämättä piirin tarkkaa kytkentää ja piirilevyn rakennetta ja koska en ole RF-asiantuntija, mutta tulee mieleen että ko. linjat esim. kapasitiivisesti vaikuttaisivat (tosin silloinhan kai nimenomaan muutos vaikuttaisi) piirilevyllä joko lähetteeseen tai kellotaajuuteen.
Kiinalainen laite voi tietysti noudattaa CC110L:n datalehden ehdotuksia omalla tavallaan. Kaikki on piilossa metallikuoressa, jota en viitsi lähteä juottamaan irti. Toisaalta kun vika tulee vain Raspberry Pi Picolla eikä lainkaan isommalla Raspberry Pi:llä, loogisesti myös Picossa pitää olla jokin syy ongelmaan ja sen kuvittelisi olevan korjattavissa jollain melko yksinkertaisella filtteröinnillä tms.
Grez kirjoitti:
Workaround voisi olla varmistaa, että kumpikaan pinneistä ei ole nollassa hyötylähetteen aikana.
Joo, tämän mainitsin jo edellä toimivaksi, mutta SPI:n yli tämä rajoittaa sitten viestit 64 tavuun (sisäisen puskurin koko). Tietysti tähän voi syöttää lähetettävää dataa myös SPI:n ohi erillistä linjaa pitkin, mutta se vaatii ihan omat säätönsä kellon kanssa, ja olisi kiva ylläpitää vain yhtä versiota koodista.
Ja erityisesti ihan periaatteesta ja muita mahdollisia projekteja ajatellen olisi kiva ymmärtää ongelman perimmäinen syy ja oikea ratkaisu. :)
Tarkistaisin, että RF-moduulin virransyöttö on varmasti kunnossa. Epämääräiset sekoilut selittyisivät hyvin sillä, että piirin jännite ei pysy vakaana. Selitystä tukisi myös se, että häiriö esiintyy pelkällä preamblella ilman ulkoista syötettä. Pystytkö mittaamaan jännitteitä oskilloskoopilla?
Menee jo vähän arpomiseksi, mutta kannattaa myös varmistaa, että käyttöjännite on kytketty oikeaan paikkaan. Jos moduuli olisi kytketty väärin ja saisi käyttöjännitteen input-pinnien suojadiodien kautta, pinnien tila vaikuttaisi tietysti moduulin toimintaan.
-tossu- kirjoitti:
Tarkistaisin, että RF-moduulin virransyöttö on varmasti kunnossa.
Kiitos, tästä se vika löytyi. ”Tarkista virtajohto” on tietysti IT-tuen klassikko, mutta ei tullut mieleenkään, että laite voisi toimia noin hyvin ilman varsinaista käyttöjännitettä. Juuri kyseisen pinnin kohdalla naarasliitin oli liian väljä eli laitteen tavallista ohuempi pinni ei saanut kontaktia. (Tuossa on ärsyttävästi 2 mm rasteri ja aika pienet pinnit.) Korjailin liitintä, ja nyt kaikki toimii.
Vaikka testeissä vaihdoin RF-moduuleja päittäin, en kokeillut vaihtaa niiden johtoja, kun SPI toimi. Kuitenkin siis CS ja MOSI yhdessä riittävät ylläpitämään toimivaa radiolähetystä (speksien mukaan 20 mA käyttämälläni teholla) ja laite ei tilttaa edes 2 ms virrankatkaisuun (kun 250 Hz:n SCK käy nollassa ja MOSI lähettää nollabittiä).
Kiitos tossulle ja myös Grezille debuggausta ohjanneista ideoista.
Aihe on jo aika vanha, joten et voi enää vastata siihen.