Home Achtergrond Testen Testversies Modules

Welke beperkingen heeft een module?

Het Arduino-ontwikkelbord heeft maar een beperkt aantal in- en uitgangen. Ook is het oppervlak van de opsteekprint beperkt.

een van de 4-knops ontwikkelmodellen

mijn 6-knops ontwikkelmodel

bruikbare encoders

Modulaire bouw

Ik heb de modules zo ontworpen dat ze in de basis zelfstandig, maar eventueel ook aanvullend naast een andere module gebruikt kunnen worden. Zo wordt de bediening voor minder valide gebruikers ook een stuk handiger. Wel moeten er voldoende knopbediende functies in de SDR ontvangstsoftware worden aangeboden en voldoende USB poorten zijn, maar daarvoor zijn er USB hubs.

Problemen bij het ontwerpen

Omdat een Arduino Leonardoprint maar 5 ingangen met een interrupt heeft (pin 0, 1, 2, 3, 7) is het niet het meest handige ontwikkelboard om meteen mee te beginnen. Prijstechnisch daarentegen is het wel interessant en ook is het een handig formaat om een 4 encoderprint voor te ontwerpen. Het gebruik van die 4 encoders zou betekenen dat er 8 interrupt-ingangen nodig zijn (in functies: 4x hoger en 4x lager) en dat zijn dus nu al 3 interrupts te weinig... In een matrix werken zou het geheel nog gecompliceerder maken, dus daar heb ik ook maar even van afgezien. Daardoor worden er wel eisen gesteld aan de hier gebruikte encoders en kan je niet zomaar meer elk type gebruiken, fysiek verschillen ze namelijk aanzienlijk. Met deze beperkte mogelijkheden iets werkends maken werd opnieuw mijn doel en vooruitziend op een eventueel bounce-effect moest er preventief misschien ook nog een de-bouncecircuit met een R-C combinatie op de print komen.

Doe mij maar alles...

Al die aansturingen zijn overigens wel uniek voor elk programma en een 'doe mij maar alles' module, die is er ook nog niet. Er is ook geen standaard voor aan functie gekoppelde hotkeys. Wel zijn er programmaatjes die toetsenbordcodes kunnen omzetten, alleen is er door de ingebouwde debounce-aanpassing dan geen garantie meer te geven op correcte werking.

Help... !

Er kwam nog een probleem om de hoek kijken, want hoe ontwerp je eigenlijk een functionele print?!

De eerste testversies heb ik met draadjes en soldeerwerk op gaatjesprint gemaakt, want terug naar de basis is voor mij niet zo'n probleem... Maar het ontwerpen van printen met alleen de kennis van wrijfsymbolen en Eddingstiften.., tja.. dat gaat het hem in de tegenwoordige tijd niet meer worden.
Dus heb ik over mijn idee -tijdens de Twentse Soldeerboutronde die op 145.600 MHz in Oost Nederland tijdens de coronatijd te volgen is geweest- contact gehad met collega radiozendamateurs, over: hoe doe je dit, waar doe je dat...? Collega Lex (PH2LB) wist er wel wat op, de print is in overleg met hem ontworpen en de productie van de printplaten heb ik ook in overleg met hem uitbesteed. Inmiddels heb ik een kleine hoeveelheid encoders op voorraad om mee te experimenteren, maar het probleem is: ze worden vaak gebruikt bij projecten en zijn daardoor erg moeilijk leverbaar!

Niet leuk..

Mijn eerste ontwerpen wilde ik in den beginne ook maar voor 1 toepassing gebruiken: SDR-Sharp in combinatie met de RTL-USB stick. Ik kende niet anders, wilde niet anders en tot zover ging dat dan ook prima! Na de SDR-Sharp versies 1716 en ook nog 1732, had men bij dat programma ineens andere ideetjes over het ontwikkelen van software. Na die versies ging er bij mij, en bij andere ontwikkelaars ook, van alles mis. Ik had al wel erg leuke interfaces ontworpen en die werkten allemaal prima... tot aan dat moment...

Op de latere SDR-Sharp versies werkten mijn interfaces (en ook die van andere ontwikkelaars) ineens niet meer, of in ieder geval niet meer betrouwbaar. Dat komt omdat er een plugin (uitbreidingsmodule) van een externe maker of partij nodig is en die twee ontwikkelaars hebben, noem het maar zo.., verschil van inzicht. Samenwerking liep mijns inziens vast op een niet optimale communicatie tussen programmaontwikkelaar(s) enerzijds en pluginontwerpers en gebruikers anderzijds. Het veranderen van ontwikkelplatform werd mede ingegeven door een al langer durende strijd over het blokkeren van concurrerende ontvangers. De gebruiker trekt nu aan het kortste eind en de pluginontwerper heeft alle moeite voor niets gedaan. Om mee te gaan in de eenzijdige ontwikkeling moeten door alle partijen flinke kosten gemaakt worden, en dat is m.i. geen hobby meer te noemen. Mocht men ooit nog bakzeil halen en de vrede stichten (ik verwacht het niet), dan houd ik me er opnieuw weer mee bezig, maar voorlopig stopt het voor mij dan ook bij SDR-Sharp versie 1732.

Alternatieven..

Zo ben ik min of meer uit noodzaak overgegaan op de HDSDR software en ja.., ik weet het, SDRuno, SDR++, SDRangel, SDRconsole en vele anderen zijn er ook nog en ze houden dan ook zeker mijn aandacht. Alleen, ik moest weer opnieuw ergens mee beginnen en wilde het Windows besturingssysteem ook nog blijven gebruiken. Achteraf heb ik dan ook zeker geen spijt van de overstap naar HDSDR en had dat misschien al veel eerder moeten doen. Dan was mij de ergernis over het gedrag dat ik daarvoor had ondervonden bij SDR-Sharp ook bespaard gebleven.

HDSDR

Dit programma is eigenlijk een doorontwikkeling van het WinRad(HD) programma, dat werd gemaakt door I2PHD (Alberto) en WA6KBL (Jeffrey).
Het is breed inzetbaar en werkt dan ook met veel ontvangers (ook de RTL-SDR en RSP modules), maar de ontwikkeling bleef wat achter. Daarop zijn er wat varianten ontstaan en DG0JBJ (Mario Taubel) bracht HDSDR weer terug in 'the Spotlights' door veel functionaliteit toe te voegen. Tot op de dag van vandaag gaat die ontwikkeling nog steeds door...
Wat bij dit programma bijzonder aangenaam is, is dat veel functies met zogenaamde 'hotkeys' zijn uitgerust en veel daarvan zijn dan ook aanwezig op de door mij gemaakte SDR-Controllers.