Iemand ervaring met de CC110L-chip?

Zijn de niet werkende ontvangers wel goed werkend te krijgen door de load-caps van het crystal aan te passen?

Er lijkt niets mis met de load-condensatoren van het kristal; ik meet een stabiele 27 MHz met een tolerantie die binnen de specificaties van het kristal valt.

Bovendien werken de ontvangers wel met het ene type zender, maar niet het andere -- en het enige verschil is dat de falende zender een iets hogere basisfrequentie heeft (ca. 869,23 MHz in plaats van 869,20 MHz). Wanneer ik in de CC110L van de ontvanger een overeenkomstig hogere basisfrequentie instel, werkt die ene zender ook weer.

Het lijkt erop dat de ontvangers veel smalbandiger zijn dan de instelling van de bandbreedte suggereert, maar ik snap niet hoe dit kan gebeuren.

Dubbelcheck de instellingen. Kan je de registers teruglezen?

Ik heb gisteren wat voorbeeldcode aan zitten passen en foutje gemaakt
waardoor ik ADC1 = 2 | 4; bleek te doen ipv ADC1 = 2, ADC2 = 4.. (adc1 en 2 zitten in hetzelfde harware register, maar het schuiven ging dus fout.

Dat soort foutjes haal je er uit door het register terug te lezen en te kijken (evt met de hand) of wat er staat ook is wat je bedoelt. (ben ik gisteren niet aan toegekomen. Ik vond hem voordat ik dat soort noodmaatregelen moest nemen... )

Op maandag 15 juli 2024 17:00:08 schreef Richard Rasker:
Er lijkt niets mis met de load-condensatoren van het kristal; ik meet een stabiele 27 MHz met een tolerantie die binnen de specificaties van het kristal valt.

Bovendien werken de ontvangers wel met het ene type zender, maar niet het andere -- en het enige verschil is dat de falende zender een iets hogere basisfrequentie heeft (ca. 869,23 MHz in plaats van 869,20 MHz). Wanneer ik in de CC110L van de ontvanger een overeenkomstig hogere basisfrequentie instel, werkt die ene zender ook weer.

Het lijkt erop dat de ontvangers veel smalbandiger zijn dan de instelling van de bandbreedte suggereert, maar ik snap niet hoe dit kan gebeuren.

Hebben de settings MDMCFG4.CHANBW_E en MDMCFG4.CHANBW_M (Receiver Channel Filter Bandwidth) invloed op het gedrag van de falende ontvangers (bijv. werken ze wel op de maximale bandbreedte instelling)?

@rew
Alle registers krijgen de gewenste waarden (ik gebruik SmartRF Studio 7 om de registerwaarden te genereren, en dat is inderdaad wel nodig gezien de vele gecombineerde registers).

@Bobosje
Hier even de FSK-frequenties van de drie zenders waarmee ik test:

TX1: 869.193 MHz - 869,220 MHz (d = 27 kHz)
TX2: 869.230 MHz - 869.270 MHz (d = 40 kHz)
TX3: 869.234 MHz - 869.264 MHz (d = 30 kHz)

Ik heb momenteel de ontvanger op een basisfrequentie van 869.199707 MHz staan, met de bandbreedte standaard op 168.75 kHz en de IF op 395.50781 kHz.

TX1 en TX2 worden correct herkend. TX3 wordt niet herkend, ook niet als ik de bandbreedte maximaal maak (843.75 kHz).

Wanneer ik de bandbreedte smaller maak dan ca. 120 kHz, valt ook TX2 buiten de boot. TX1 wordt altijd herkend, ook bij de laagst mogelijke bandbreedte (60.267857 kHz).

Het gaat allemaal goed wanneer ik de basisfrequentie enkele tientallen kHz omhoog gooi naar 869.239258 MHz, dus slechts een kleine 40 kHz hoger.
Dit vind ik dus vreemd -- die bandbreedte-instelling zou dit toch ruim moeten dekken? Het helpt ook niet wanneer ik de basisfrequentie aanzienlijk hoger maak, bijvoorbeeld 869,300 (dus 100 kHz hoger dan de nominale waarde), want dan werkt TX1 niet meer, ook niet als ik de bandbreedte flink ruimer maak.

Ik vermoed dat ik belangrijks mis en dus verkeerd doe.

Met welke baudrate (of bits per seonde) en welk bit patroon van de data-transmissie test je de FSK verbinding?
Of falen de ontvangers ook zonder actieve data-transmissie (zien ze al geen carrier frequentie)?

De zenders produceren een Manchester-encoded FSK-signaal, ontworpen voor gebruik met de ATA5760-chip. Dit ziet er zo uit:

Het gele signaal wordt hoog als de zenderchip (TC5705C) is ingeschakeld.
Het blauwe signaal is de modulatie, met L = lagere FSK-frequentie, en H = hogere FSK-frequentie:

1. Na inschakelen wordt eerst gedurende 10 ms een draaggolf met de lage FSK-frequentie uitgezonden.
2. Daarna volgen 24 bits preamble gestuurd, gevolgd door één geïnverteerd sync-bit, met een datarate van 1 kbaud. De CC110L blijkt niet overweg te kunnen met deze Manchester-encoding(*), en dus wordt die preamble + sync beschouwd als een 15/16-bit sync-woord 0x55 0x56 (SYNC1:SYNC0), en dat gaat goed wanneer in de CC110L de dubbele datarate wordt ingesteld, dus 2 kbaud.
3. Na het sync-bit/word volgt de eigenlijke payload van 3 bytes. Als gevolg van de dubbele datarate krijg ik 6 bytes in de RX-buffer, die telkens per 2 bits gedecodeerd moeten worden (10 => 0, 01 => 1).

*: De reden hiervoor is niet helemaal duidelijk, en ook de expert in het TI-form (https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1…) kon hier geen goede verklaring voor geven.

Wanneer het in de ontvanger misgaat, krijg ik in ieder geval geen SYNC_RECEIVED_OUT (GDO0_CFG = 0x06).
Met het uitgezonden signaal in geel en blauw aan de asynchrone data-out van de ontvanger (GDO2 = 0x0D) ziet het er als volgt uit:

Zolang de zender uit staat, wordt alleen ruis ontvangen op de Serial Data Output. Zodra de zender actief wordt, stopt deze ruis, dus de draaggolf wordt absoluut herkend. Dit geldt echter niet voor de modulatie. Ter vergelijking exact dezelfde opzet, maar nu met een zender die wel wordt herkend:

De draaggolf wordt herkend, alsmede een deel van de preamble. Dit laatste zou trouwens wel eens een hele goede aanwijzing kunnen zijn voor wat er mis is: kennelijk heeft de CC110L nogal wat tijd nodig om de bit-stream correct te herkennen.
Dit is ook duidelijk te zien wanneer ik inzoom op het begin van de preamble zoals die uit de ontvanger komt:

Eerst komen de bits helemaal niet door, en daarna nemen de eerste doorkomende bits gaandeweg af in duty-cycle, om pas ergens bij de laatste 8 op de juiste 50% te zitten.En ja, het aantal zichtbare preamble-bits neemt af naarmate de basisfrequentie van de ontvanger verder weg ligt van de zenderfrequentie (hier met de frequentie aan de ontvangerkant nog iets verlaagd):

De vraag is hoe dit komt, of alles wel goed werkt als het verholpen is, en natuurlijk vooral ook hoe dit opgelost kan worden. Ik hoop dat de oplossing aan de ontvangerkant gerealiseerd kan worden, want daarvan zijn er momenteel slechts enkele tientallen, dus dat is nog te overzien om aan te passen.

Hoe dan ook, alvast erg bedankt voor het meedenken en vragen stellen -- het dwingt me tot systematisch foutzoeken met nu al een eerste goede aanwijzing!

Dank voor de uitgebreide en duidelijke uitleg.

Waar ik aan zit te denken is het feit dat FSK modulatie nogal een (erg) breed frequentie spectrum kan hebben (vooral bij relatief hoge data-rates met afwisselende data L en H zoals in je info) en dat de ontvanger een voldoende breed spectrum van dat FSK signaal nodig heeft / correct moet kunnen ontvangen om de data correct te kunnen decoderen.

Kun je dezelfde testen eens uitvoeren met een data-rate van 10 of 100 of 500 baud (i.p.v. de 1kbaud) en kijken of de falende ontvangers dan beter presteren?

Testen met een lagere data-rate wordt wat lastig, dan moet ik zenders gaan omprogrammeren. Dit zou voor een test nog wel te doen zijn, maar is bijzonder ongewenst als oplossing -- er zijn talloze zenders in omloop bij tal van eindklanten.

Ik denk overigens ook niet dat de oplossing in die hoek gezocht moet worden, want SmartRF Studio biedt een grote waslijst configuraties voor uiteenlopende baudrates -- allemaal 1,2 kbaud of hoger, tot 250 kbaud aan toe:

Ik zal morgen eens een paar van die configuraties in detail nalopen om te zien hoe die verschillen van mijn configuratie. Hopelijk levert dit een 'aha-moment' op ...

Een andere oorzaak is mogelijk die 10 ms draaggolf zonder modulatie aan het begin. Zolang er ruis wordt gedetecteerd, blijft de signaaldetectie keurig 'halverwege', en zou er een probleemloze overgang naar een eveneens snel wisselend signaal moeten zijn. Een ongemoduleerde draaggolf op de lage FSK-frequentie echter lijkt de detectie steeds verder uit het middengebied te trekken, en wel meer/sneller naarmate het frequentieverschil groter is. Maar dit zou dan toch een nogal beroerd detectorontwerp zijn ... In een legitieme data-stream kunnen immers ook iets langere perioden met alleen 0 of 1 optreden, en daar mag de ontvanger niet op ontsporen.

Maar wederom dank voor het meedenken! (Ik heb de voorgaande bevindingen trouwens ook meteen maar even op het TI-forum geplaatst, misschien dat dit een van de techneuten daar bekend voorkomt.)

[Bericht gewijzigd door Richard Rasker op maandag 15 juli 2024 22:35:29 (28%)]

In een legitieme data-stream kunnen immers ook iets langere perioden met alleen 0 of 1 optreden (...)

Met manchester codering zou dat juist niet het geval moeten zijn. In dat opzicht is die 10ms zonder modulatie ook wat vreemd als je stelt dat de zender manchester codering toepast...

Hebben de zenders FSK modulatie of GFSK modulatie? En waarop staan de ontvangers op ingesteld, FSK of GFSK?

https://gathering.tweakers.net/forum/list_messages/1976492

Kon je dit topic sl op GoT? Zit een cc1101 in , ongeveer dezelfde use case

Op maandag 15 juli 2024 22:27:36 schreef Richard Rasker:
Dit zou voor een test nog wel te doen zijn, maar is bijzonder ongewenst als oplossing -- er zijn talloze zenders in omloop bij tal van eindklanten.

Een deel van de suggesties is niet om als "oplossing" dienst te doen, maar om te helpen bij de "diagnose". Dit is er zo eentje.

IK denk niet dat het stukje "geen data" aan het begin een probleem is. De "detectie in het midden" is waarschijnlijk niet juist: Hij heeft z'n ontvangstversterker op maximale gain gezet zodat er toch overgangen worden gedetecteerd. Als er een ontvangbaar signaal in de buurt is, dan moet de ontvangstversterker ineens veel minder versterken. Daar is dat stukje constante data voor, om die ontvangstversterker de tijd te geven bij te regelen.

Het lijkt er op dat er een tijdconstante te langzaam staat. Kan je daar wat aan instellen? Met externe componenten? Of alleen in software?

Edit: Even het datasheet aan het bekijken. Wat heb je in FOCCFG gezet?

Op dinsdag 16 juli 2024 08:28:06 schreef rew:
Een deel van de suggesties is niet om als "oplossing" dienst te doen, maar om te helpen bij de "diagnose". Dit is er zo eentje.

Zeer juist.
Eerst de oorzaak proberen te achterhalen dan toewerken naar een werkbare oplossing.
De techneuten op het TI forum dragen ook niet echt een oplossing aan.

Ook de vraag of alle zenders en ontvangers op FSK of op GFSK modulatie staan kan relevant zijn.

Even in volgorde de antwoorden:

@PE9SMS: Manchester-codering is inderdaad een veel gebruikte manier om de gemiddelde DC-waarde van een signaal op nul te houden. Dit is echter optioneel in de CC110L, en ik heb de indruk dat dit tegenwoordig niet veel meer wordt gebruikt. Overigens weet ik niet hoe de niet-Manchester-coderingen eruitzien.

@Bobosje: alles is ingericht op simpele 2-FSK; de zender wordt gemoduleerd door een schakelcondensator in serie met het kristal van een T5750C al dan niet met massa te verbinden, zie pagina 5 van de datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-4546-Car-Access…. Dit gebeurt digitaal, dus gewoon hard 0 of 1.

@joopv: Ja, ik weet dat de CC110L een El Cheapo-versie van de CC1101 is, en ik heb het artikel ook even bekeken -- maar ik zie daar zo snel niets over vergelijkbare problematiek als die ik tegenkom.

@rew: Ja, dat van die tijdconstante is een hele goede suggestie. Ik heb nog even getest met een proto-exemplaar van vorig jaar dat het wel altijd goed deed, en ook die vertoont dit gedrag van vertraagd opkomende preamble-bits, alleen op een ietwat lagere frequentie -- exact overeenkomend met de iets afwijkende 27 MHz kristalfrequentie.
En dan FOCCFG: daar staat nu 0x16, overgenomen van SmartRF Studio. Dit betekent dus 3K loop-gain frequentiecompensatie vóór het sync-word, K/2 erna, en een f-offsetcompensatie-verzadigingspunt de ingestelde bandbreedte gedeeld door 4.
Overigens is er dus ook nog het hierop volgende register BSCFG, zo te zien voor de versterking van de integratielus waarmee de clock-recovery plaatsvindt. Dit register heeft hier de waarde 0x6C. En dan zijn er nog allerlei AGC-instellingen (0x03, 0x40 en 0x91 voor resp. AGCCTRL2, AGCCTRL1 en AGCCTRL0).
Helaas ben ik te slecht thuis in dit soort 'ontvangerparameters voor gevorderden' om te kunnen beredeneren of berekenen of en hoe het beter kan; hier zou ik dan nog weer uitgebreid in moeten duiken. Ook werd mij een jaar geleden op het TI-forum sterk aangeraden om gewoon de waarden van SmartRF Studio over te nemen, tenzij ik heel zeker wist wat ik deed. En trial-and-error lijkt me gezien de veelheid van parameters ook geen goede aanpak.

Suggesties voor verbetering/tests zijn kortom absoluut welkom. Ik zal in de tussentijd de zender toch nog even ontdoen van die 10 ms ongemoduleerde draaggolf, gewoon om te zien wat er dan gebeurt.

Op dinsdag 16 juli 2024 11:48:31 schreef Richard Rasker: Ik zal in de tussentijd de zender toch nog even ontdoen van die 10 ms ongemoduleerde draaggolf, gewoon om te zien wat er dan gebeurt.

OK, even die 10 ms weggehaald, en nu gaan er veel minder (als in: bijna geen) preamble-pulsen verloren:

Ter vergelijking nog een keer exact dezelfde combinatie van zender en ontvanger met die 10 ms vertraging:

Het lijkt me dus in ieder geval een erg goed idee om in nieuw te bouwen zenders die vertraging weg te laten.

In het lijstje (https://www.circuitsonline.net/forum/view/message/2522582#2522582) staat alleen GFSK modulatie genoemd maar geen FSK modulatie.

FSK is veel breedbandiger dan GFSK dus als de zender FSK uitzendt en de ontvanger GFSK verwacht dan kan het zijn dat de ontvanger modulatie informatie mist (buiten de bandbreedte ligt) om het signaal correct te kunnen decoderen.

Maar mogelijk is het lijstje niet compleet en staan er ook profielen in voor FSK...

Nee, die profielen zijn inderdaad allemaal voor GFSK. Maar het oude zendertype kan geen GFSK uitsturen, alleen 2-FSK. En ja, dat lijkt inderdaad veel breedbandiger te zijn door de abrupte overgangen. (Ik leer hier een hoop nieuwe dingen!)

Overigens heb ik ook al aan mijn klant voorgesteld om de zenders eveneens opnieuw te ontwerpen met een CC110L als TX-chip. Daarmee zou het een stuk simpeler moeten worden om de boel goed aan de praat te krijgen, met meer vrijheid in de keuze voor het hele protocol van sync-word en dataformaat.

Maar ja, zo'n aanpassing in een op zich nog werkend en produceerbaar ontwerp kost een behoorlijke bak geld, en dat wordt slechts met tegenzin uitgegeven, wanneer er feitelijk geen keuze meer is.

En daarom vroeg ik ook om eens met 10, 100 of 500 baud te testen om het FSK spectrum van de zenders wat smaller te maken voor de ontvangers zodat deze meer demodulatie informatie krijgen voor een betere verwerking van het signaal...
Het is geen oplossing maar kan bijdragen aan de probleem vinding...

Ik zit nog even te kijken naar je scope trace....

Kan je voor een test die "eerst een stukkie niets" er uit slopen, Direct met de preamble beginnen. Mogelijk reageert de CC110L daar beter op.

Weer: Niet direct handig als oplossing, maar hopelijk helpt het om te begrijpen waar het mis gaat.

Op dinsdag 16 juli 2024 16:13:46 schreef rew:
Kan je voor een test die "eerst een stukkie niets" er uit slopen ...

Dat is dus precies wat ik heb gedaan in mijn voorlaatste post (16-07 12:24), en het antwoord is dus dat dit inderdaad een enorm verschil maakt.
In het bovenste plaatje is te zien dat er dan vrijwel geen preamble-bit meer verloren gaat, vergeleken met de oude situatie (onderste plaatje).

Het lijkt er dus toch op dat een ongemoduleerde draaggolf een of ander detectorniveau in de CC110L in het honderd stuurt.

Overigens gaat het bij veel zenderproducten die nog wel zo'n 'aanloop' hebben ook goed, zolang de basisfrequentie maar dicht in de buurt ligt.
Ik denk dat het het beste is om een setje zender-ontvanger vóór inzet bij een klant te testen, en de zender om te programmeren als deze nog problemen geeft.

Het lijkt er dus op dat de boel nu in ieder geval inzetbaar is; ik zal toch ook maar aandringen op het in gang zetten van de ontwikkeling van een zendercircuit op basis van de CC110L.

Verdere tips voor optimalisatie zijn natuurlijk welkom, maar ik ben nu in ieder geval al erg blij, na toch de nodige dagen zonder veel resultaat aanprutsen ... het helpt enorm wanneer iemand anders met een kritische blik kan meekijken en mij bij de les houdt

Dus alvast heel erg bedankt iedereen!

Waarom de zenders omprogrameren wanneer sommige ontvangers het wel gewoon doen. Dan zou ik eerder de zenders laten voor wat ze zijn en de ontvangers tunen op de juiste basis frequentie van een zender en steeds een getuned setje zender/ontvanger afleveren.

Op dinsdag 16 juli 2024 16:41:13 schreef Richard Rasker:
[...]
Dat is dus precies wat ik heb gedaan in mijn voorlaatste post (16-07 12:24),

Oeps. Sorry! Ik zat te staren naar het laatste plaatje van de posting en heb "goh, dat stond toch eigenlijk eerder in deze thread?" genegeerd.

Het lijkt er dus toch op dat een ongemoduleerde draaggolf een of ander detectorniveau in de CC110L in het honderd stuurt.

Nee (denk ik), die ongemoduleerde draaggolf ziet hij als "de middenfrequentie". Hij is dan afgesteld om lagere frequentie als "0" en hoger als "1" te zien (of andersom).

De CC110L ondersteund 2-FSK modulatie (MOD_FORMAT[2:0] = 0) echter als ik de datasheet goed interpreteer dan alleen op de 315Mhz band......