Sinds ik twee jaar geleden mijn 2e hands Quest heb gekocht ben ik een fietscomputer voor mijn Quest aan het ontwikkelen. Ik sta op het punt een aantal laatste aanpassingen te doen, met name aan de hardware.

Ik kan deze nieuwe versie weer op prototype breadboards solderen, maar mochten er meer mensen interesse hebben dan overweeg ik om er printplaat van te ontwerpen en te laten maken. Dat is professioneler, minder foutgevoelig én het kan allemaal net wat compacter.

De huidige versie (en de komende ook) is opensource en staat gewoon op GitHub: https://github.com/JanBurp/VeloDashboard
Hier kun je ook lezen wat de computer allemaal kan. Je kunt er het (ruwe) schema zien, een ontwerp voor het huidige dashboard wat je dan kunt 3D printen. En nog wat meer. Nog geen foto's oid. Dan hoop ik binnenkort te doen.

Wie heeft er interesse in een DIY pakketje? Bestaande uit:
- printplaat voor de computer
- printplaat voor het dashboard
- eventueel, als je geen printer hebt, een 3D print van het dashboard

Tzt zal de GitHub pagina worden uitgebreid met een uitgewerkt schema, een BOM en wat tips voor installatie/handleiding.

PCB's moet je minimaal per 5 afnemen, twee wil ik er zelf wel, dus mochten er 3 of meer mensen zijn die interesse hebben, dan ga ik PCB's overwegen.

Kosten voor het DIY pakketje? Precies weet ik het niet, ik schat ergens tussen de € 20,- en € 50,-.

NB Verwacht geen kant en klaar product, dus je moet zelf je handen uit de mouwen steken om de boel te solderen, in je velo te monteren, en de software op de Teensy te zetten. Uit eigen ervaring kan ik zeggen dat het inbouwen in de velo het lastigste is ;-)

Interessant product. Ga je dan ook bijhouden wanneer je op de rem hebt gedrukt ? En de hartslag , cadans , snelheid , vermogens sensoren uitlezen ? Zelf ga ik het product nog niet inbouwen. Wil in mijn vrij nieuwe VM niet heel de draad structuur veranderen

Ja de rem schakelaar is onderdeel en heeft dus effect op de verlichting. En snelheid en aanverwanten zeker. Vermogen, hartslag ed vind ik zelf minder interessant, dus heb ik er niet ingebouwd. Maar op de volgende hardware versie komen aansluitingen om eventueel zelf extra diy sensoren aan te sluiten.

Met dat idee heb ik ook al gespeeld. Maar dan met een ESP32/8266 en esphome. Simpele yml file. Alleen ontbreekt me de tijd om me er eens aan te zetten.

Als je toch bezig bent zou je ook de gelegenheid kunnen gebruiken de zaak flink overhoop te halen. Dat hele gedoe met kabelbomen ziet er altijd complex en storingsgevoelig uit. Als je ieder licht zijn eigen micro en FET geeft kan je een busstructuur opzetten. Dan zitten alle verbruikers parallel aan dezelfde (maximaal 4) draden. I2C of CAN zouden goede kandidaten zijn.
Technisch is het niet erg ingewikkeld, wel een berg werk omdat elk licht zijn eigen pcb moet hebben en je iets van een communicatie protocol moet verzinnen dat een beetje toekomstbestendig is.

Ah nice, ik heb ook al meermaals over iets dergelijks nagedacht maar met mijn nieuwe fiets ben ik minder geneigd om de Willy Wortel uit te hangen.
Als ik tijd vindt zal ik Kicad weer even installeren om te bekijken wat je nu hebt. Heb net een nieuwe laptop en op kantoor gebruik ik altium dus Kicad staat er nog niet op.
Waar ik in mijn hoofd ook wel mee speel is juist een computer die mijn sensoren uitleest (Ant+) dan kan ik de interface daarvan in mijn fiets verwerken (en bijvoorbeeld een ant+ antenne bij mijn achterwiel plaatsen want met mijn nieuwe carbon fiets heeft mijn snelheidssensor in mijn achterwiel geen verbinding meer.

(14-Jul-2024, 07:08 PM)Merijn schreef: Als je toch bezig bent zou je ook de gelegenheid kunnen gebruiken de zaak flink overhoop te halen. Dat hele gedoe met kabelbomen ziet er altijd complex en storingsgevoelig uit. Als je ieder licht zijn eigen micro en FET geeft kan je een busstructuur opzetten. Dan zitten alle verbruikers parallel aan dezelfde (maximaal 4) draden. I2C of CAN zouden goede kandidaten zijn.
Technisch is het niet erg ingewikkeld, wel een berg werk omdat elk licht zijn eigen pcb moet hebben en je iets van een communicatie protocol moet verzinnen dat een beetje toekomstbestendig is.

Interessant idee, en inderdaad die kabelbomen vindt ook niet het mooiste/handigste. Ik heb een tussenvariant overwogen en uitgetest om het dashboard (de knoppen aan het stuur) met I2C te verbinden en zo daar meer 'ruimte' te hebben. Bijvoorbeeld meer knoppen, LED's (of strips) of zelfs het OLED display in het dashboard op het stuur. Maar ik zat al snel aan de grens van de kabellengte voor zo'n bus, het gaf allerlei problemen (geen signaal of gebrekkig). Ik ben dus met die variant gestopt.

---

(14-Jul-2024, 04:55 PM)bucovaina schreef: Met dat idee heb ik ook al gespeeld. Maar dan met een ESP32/8266 en esphome. Simpele yml file. Alleen ontbreekt me de tijd om me er eens aan te zetten.

Dat is ook een mooie richting inderdaad. En inderdaad, het kost allemaal behoorlijk veel tijd ;-)

---

(14-Jul-2024, 11:45 PM)Boyd Maduro schreef: Ah nice, ik heb ook al meermaals over iets dergelijks nagedacht maar met mijn nieuwe fiets ben ik minder geneigd om de Willy Wortel uit te hangen.

Zou ik ook niet zo snel doen op een nieuwe fiets. Hoewel dit voor Bulk4More eigenaren die geen electronica hebben misschien nog wel interessant kan zijn.

(14-Jul-2024, 11:45 PM)Boyd Maduro schreef: Als ik tijd vindt zal ik Kicad weer even installeren om te bekijken wat je nu hebt. Heb net een nieuwe laptop en op kantoor gebruik ik altium dus Kicad staat er nog niet op.
Waar ik in mijn hoofd ook wel mee speel is juist een computer die mijn sensoren uitleest (Ant+) dan kan ik de interface daarvan in mijn fiets verwerken (en bijvoorbeeld een ant+ antenne bij mijn achterwiel plaatsen want met mijn nieuwe carbon fiets heeft mijn snelheidssensor in mijn achterwiel geen verbinding meer.

Ben benieuwd naar wat je ervan vindt als je de boel in KiCad bekijkt. Hopelijk ergens in de komende weken push ik de laatste versie.

Zou leuk zijn als iemand het hele ant+ verhaal zou kunnen inbouwen (dat is het leuke van een opensource project). Ik heb daar niet zoveel mee, maar dat zou het wel generieker maken voor meer gebruikers.

---

NB Heb de titel van de thread aangepast naar 'DIY opensource fietscomputer voor Velomobiel', leek mij iets beter passen ;-)

Ik kan nog wel wat dingen bedenken:
- instellingen menu waar je oa ook de zoemer aan/af kan zetten voor de pinkers of misschien zelfs het volume kan regelen. Sommige mensen houden er niet zo van.
- stel dat je naar een RPI zero W zou gaan (verbruik ~1W idle), kan je er meteen ook naar SSH'en en gegevens uitlezen of gegevens bij aankomst (WiFi available) uploaden naar een sFTP server thuis of zo. Daar hangen dan ook weer wat nadelen aan vast natuurlijk. Batterij uittrekken, trek je ook de stroom van de RPI eraf. Gaat haast altijd goed, maar met een draaiende Linux misschien niet best practice. Ook een SD-card is niet de beste storage, al valt het in de praktijk best mee. Ik zou dan vaak backups maken een ergens een ansible playbook hebben die bij vervanging van de SD-card, binnen 5 minuten alles terug op orde heeft staan.

Misschien nog een andere vraag, stel dat ik met een breadboardje eens zou willen beginnen klooien? Bestaat er ergens een lijst van de elektronica-componenten die in een velomobiel zitten? In mijn geval dan de QV? Ik zou het best wel grappig vinden om van nul iets op te bouwen.

(15-Jul-2024, 08:26 AM)bucovaina schreef: Ik kan nog wel wat dingen bedenken:
- instellingen menu waar je oa ook de zoemer aan/af kan zetten voor de pinkers of misschien zelfs het volume kan regelen. 
Sommige mensen houden er niet zo van.

Ik heb er nu een instelling menu in voor:
- Resseten van de tellers (3)
- Aanpassen van totaalteller
- Aanpassen wielomvang (kiezen uit ERTRO lijst, of zelf omvang in mm invoeren)
- Tijd aanpassen

In de huidige versie heb ik een zoemer voor de pinkers. Maar die haal ik eruit met de volgende versie: ik vind het irritant en in de nieuwe versie heb ik twee groene LED's op het dasboard (ipv indicatie op het display).

(15-Jul-2024, 08:26 AM)bucovaina schreef: - stel dat je naar een RPI zero W zou gaan (verbruik ~1W idle), kan je er meteen ook naar SSH'en en gegevens uitlezen of gegevens bij aankomst (WiFi available) uploaden naar een sFTP server thuis of zo. Daar hangen dan ook weer wat nadelen aan vast natuurlijk. Batterij uittrekken, trek je ook de stroom van de RPI eraf. Gaat haast altijd goed, maar met een draaiende Linux misschien niet best practice. Ook een SD-card is niet de beste storage, al valt het in de praktijk best mee. Ik zou dan vaak backups maken een ergens een ansible playbook hebben die bij vervanging van de SD-card, binnen 5 minuten alles terug op orde heeft staan.

Heb ik even overwogen. RPI's gebruik ik ook wel voor andere dingen, maar vind de opstarttijd te lang voor een fietscomputer, ik wil niet wachten met fietsen... ;-) De Teensy heeft iig een SD kaart optie, dat vindt ik voldoende voor mogelijke toekomstige toepassingen (in mijn versie gebruik ik dat niet, maar is redelijk eenvoudig in te bouwen).

(15-Jul-2024, 08:26 AM)bucovaina schreef: Misschien nog een andere vraag, stel dat ik met een breadboardje eens zou willen beginnen klooien? Bestaat er ergens een lijst van de elektronica-componenten die in een velomobiel zitten? In mijn geval dan de QV? Ik zou het best wel grappig vinden om van nul iets op te bouwen.

In de handleidingen staan de schema's. De onderdelen niet echt natuurlijk. Wat ik heb gedaan is een aantal powerLED's kopen en die gebruiken in mijn test-opstelling. En een keer de koplamp even aan mijn testopstelling gehangen om te kijken of het werkt.

(15-Jul-2024, 08:26 AM)bucovaina schreef: Misschien nog een andere vraag, stel dat ik met een breadboardje eens zou willen beginnen klooien? Bestaat er ergens een lijst van de elektronica-componenten die in een velomobiel zitten? In mijn geval dan de QV? Ik zou het best wel grappig vinden om van nul iets op te bouwen.

Wiring_diagram_12V_QV_2022_web (velomobiel.nl)

En hier vind je nog meer informatie over de QV en andere modellen
Velomobiel.nl - Handleiding

@hardloper: idd, die heb ik al eens bekeken, maar er staat niet op wat er net in zit. Mijn vraag is eigenlijk: "Stel dat ik de knipperlichtinstallatie op een RPI of zo zou willen zetten om thuis mee te klooien? Wat koop ik dan net om zeker te zijn dat het op de echte ook gaat werken?".

Ik zeg maar wat: stel de knipperlichten in de VM verbruiken 2x meer. Je bouwt alles in en wat ervoor op de tafel wel werkte, werkt plots niet meer, of maar half zo goed.

(15-Jul-2024, 09:59 AM)bucovaina schreef: @hardloper: idd, die heb ik al eens bekeken, maar er staat niet op wat er net in zit. Mijn vraag is eigenlijk: "Stel dat ik de knipperlichtinstallatie op een RPI of zo zou willen zetten om thuis mee te klooien? Wat koop ik dan net om zeker te zijn dat het op de echte ook gaat werken?".

Ik zeg maar wat: stel de knipperlichten in de VM verbruiken 2x meer. Je bouwt alles in en wat ervoor op de tafel wel werkte, werkt plots niet meer, of maar half zo goed.

Je zou het kunnen vragen aan velomobiel.nl.

In mijn geval heb ik mijn code zo opgezet dat ik met een simpele setting de waarden kan aanpassen om verschillen in de test en de echte setup te kunnen aanpassen. Ook wel zo handig om de powerLED's in de test setup wat minder fel in te stellen dan in de werkelijkheid ;-)

(15-Jul-2024, 09:59 AM)bucovaina schreef: @hardloper: idd, die heb ik al eens bekeken, maar er staat niet op wat er net in zit. Mijn vraag is eigenlijk: "Stel dat ik de knipperlichtinstallatie op een RPI of zo zou willen zetten om thuis mee te klooien? Wat koop ik dan net om zeker te zijn dat het op de echte ook gaat werken?".

Ik zeg maar wat: stel de knipperlichten in de VM verbruiken 2x meer. Je bouwt alles in en wat ervoor op de tafel wel werkte, werkt plots niet meer, of maar half zo goed.

Begrijp ik het goed, dat je bv exact dezelfde led / weerstandjes etc. wil gebruiken die men ook in de QV gebruikt? 

Heel eerlijk, ik denk eigenlijk dat helemaal niet zo nauwkeurige komt. Volgens mij kun zelfs gaan testen met simpele goedkopere rode ledjes om de knipperlicht functie te testen.

(15-Jul-2024, 10:43 AM)Hardloper schreef: Begrijp ik het goed, dat je bv exact dezelfde led / weerstandjes etc. wil gebruiken die men ook in de QV gebruikt? 

Heel eerlijk, ik denk eigenlijk dat helemaal niet zo nauwkeurige komt. Volgens mij kun zelfs gaan testen met simpele goedkopere rode ledjes om de knipperlicht functie te testen.

Ja dacht ik te doen, maar idd zoals je zegt, het maakt waarschijnlijk weinig uit. Eerst met het goedkoopste spul testen, dan eventueel een laatste prototype maken met "echte" LEDs. Werkt die ook volgens verwachting: inbouwen.

hey wat supertof dit! Ik weet niet of ik voldoende skills heb om het ook zelf te gaan bouwen, maar ik ben gek op Free/Libre software.

Ik denk dat ik vandaag de laatste puntjes op de i van mijn verniewde schema heb gezet. Nog niet in mijn repo. Maar ik deel het vast hier:

Dag Jan,

Zo op het eerste gezicht netjes. Een paar opmerkingen:

• Die LDD-700 is gespecificeerd op minimaal 3.5 v op dePWM ingang. Gezien het feit dat je elders een levelconverter gebruikt, neem ik aan dat Teensy IO op 3.3 v gaat. Dat zou problemen kunnen geven
  
• Is er een reden dat je soms wel pull downs gebruikt en soms niet? Die kan je op de Teensy vast ook zetten. 
  
• Als je later een ANT + interface wil toevoegen zou ik die nu al naar buiten brengen, zeker als je een pcb laat maken. Dit zou een kandidaat kunnen zijn: https://www.nicerf.com/specified-functio...51422.html (zelf geen ervaring mee, maar een seriële interface is wel praktisch).
  
• Testpunten expliciet toevoegen maakt debuggen gemakkelijker. Zeker op data interfaces. Dan kan je er indien nodig nog even een Logic analyseren op hangen. Verklikker ledjes op belangrijke lijnen is ook heel fijn. Dan kan je ook veel testwerk doen zonder een hele kerstboom op tafel. 
  

Groeten, Merijn

(17-Jul-2024, 07:56 PM)Merijn schreef: Dag Jan,

Zo op het eerste gezicht netjes. Een paar opmerkingen:

• Die LDD-700 is gespecificeerd op minimaal 3.5 v op dePWM ingang. Gezien het feit dat je elders een levelconverter gebruikt, neem ik aan dat Teensy IO op 3.3 v gaat. Dat zou problemen kunnen geven
  
• Is er een reden dat je soms wel pull downs gebruikt en soms niet? Die kan je op de Teensy vast ook zetten. 
  
• Als je later een ANT + interface wil toevoegen zou ik die nu al naar buiten brengen, zeker als je een pcb laat maken. Dit zou een kandidaat kunnen zijn: https://www.nicerf.com/specified-functio...51422.html (zelf geen ervaring mee, maar een seriële interface is wel praktisch).
  
• Testpunten expliciet toevoegen maakt debuggen gemakkelijker. Zeker op data interfaces. Dan kan je er indien nodig nog even een Logic analyseren op hangen. Verklikker ledjes op belangrijke lijnen is ook heel fijn. Dan kan je ook veel testwerk doen zonder een hele kerstboom op tafel. 
  

Groeten, Merijn

Hoi Merijn,

Bedankt voor je input! Erg welkom.

- Die LDD-700 werken al twee jaar in mijn eerste prototype prima met de 3.3V van de Teensy. Wel een andere weerstandwaarde moeten kiezen dan ze standaard (voor een Arduino setup) adviseren. Die levelconverters gebruik ik idd wel voor de LEDstrips. Die hebben wel echt de 5V nodig.
- Pulldowns kun je idd op de Teensy instellen. Dus misschien niet overal nodig idd, zal ik nog eens kritisch naar kijken. Alles wat eenvoudiger kan is mooi meegenomen ;-)
- Ik heb er nu (nog) voor gekozen om nog een versie op een prototype board te maken. Dus voor nu geen extra's die ik zelf iig niet ga gebruiken. Maar ik zal binnenkort als deze versie klaar is alles op mijn GitHub repo zetten en dan kun je forken etc natuurlijk. Zou leuk zijn als het een gezamenlijk project kan worden.
- Die testpunten is een goed idee. Heb zelf geen analyzer, maar LEDjes zijn dan wellicht wel handig. Maar goed, dat is voor een PCB versie.

Lijkt alsof je wat ervarener bent?
Ik ben vooral software-developer, hoewel ik al mijn hele leven zo nu en dan met electronica knutsel, en met wat te puzzelen en te proberen kom ik aardig ver. Dit is mijn tweede project dat ik in KiCad uitwerk. Meestal zijn het eenvoudige pen en papier schetsjes ;-)

Ik bedacht me zo ineens iets... misschien mosterd na de maaltijd, maar is het geen goed idee om in een zelfbouw fietscomputer ook dashcambeelden op te laten slaan? Zou veel meer CPU-power vereisen en mogelijk ook een chip die hardwarematig al met H.265 om kan gaan, maar toch, het zou superhandig zijn als het een one-stop shop was.
Werd er even aan herinnerd door Bucovaina z'n opmerking om reisdata direct op te laten nemen in de beelden.

(06-Aug-2024, 03:50 PM)365cycle schreef: Ik bedacht me zo ineens iets... misschien mosterd na de maaltijd, maar is het geen goed idee om in een zelfbouw fietscomputer ook dashcambeelden op te laten slaan? Zou veel meer CPU-power vereisen en mogelijk ook een chip die hardwarematig al met H.265 om kan gaan, maar toch, het zou superhandig zijn als het een one-stop shop was.
Werd er even aan herinnerd door Bucovaina z'n opmerking om reisdata direct op te laten nemen in de beelden.

Nooit aan gedacht, vast omdat ik zelf geen camera's in mijn VM heb. Maar wel weer een mooi idee. En passend bij mijn oorspronkelijke idee dat ik geen gehannis wil met meerdere losse apparaten.
Geen idee of een Teensy CPU dat aankan. Er kan in principe wel een SD kaart bij, dus het opslaan zou dan theoretisch wel moeten lukken.

Voor de versie die ik nu net heb ingebouwd inderdaad mosterd na de maaltijd. Maar alles is opensource, dus misschien een idee om te forken en uit te proberen?

---

Net trouwens de laatste code en schema gepushed. Komende dagen voeg ik ook 3D ontwerpen toe van het dashboard op het stuur en de computer zelf. En ook wat foto's (niet mijn sterkste punt ;-)

Een RPI kan dat volgens mij wel. Als ik me niet vergis kan je er tegenwoordig ook een PCIe SSD in kwijt, dan boot'ie een stuk sneller dan van SD, ook beter ivm betrouwbaarheid van de opslag.

Geen idee hoe snel een RPI-5 tegenwoordig is, maar volgens mij is'ie nog een stuk sneller dan een RPI4 waar ik vroeger nog een tijd mee geklooid heb.

EDIT: https://www.kiwi-electronics.com/en/nvme...i-5--19948 . Ik weet nu niet of hij er ook echt van kan booten, maar ik vermoed wel dat je u-boot kan laten verwijzen naar de NVMe SSD als opslag, dan zou het alsnog een stuk sneller moeten gaan dan van een SD-card.

De Rasberry Pi's 4 & 5 kunnen sowieso booten van externe media. De 3 volgens mij ook met wat werk.

(06-Aug-2024, 06:42 PM)Frutsel schreef: De Rasberry Pi's 4 & 5 kunnen sowieso booten van externe media. De 3 volgens mij ook met wat werk.

Kan maar ik heb er in mijn persoonlijke geval slechte ervaringen met de 4. Die werd erg onstabiel om een of andere bizarre reden.

Hoe snel start een moderne PI op? Ik heb wat 4's liggen en die starten voor een fietscomputer véél te langzaam op (niet gemeten, maar gevoelsmatig zeker een miniuut ofzo). Ik wil instappen, aanzetten en meteen wegfietsen zonder dat ik moet wachten ergens op. Vandaar dat ik voor mijn computer heb gekozen voor een Teensy.

Maar zoals gezegd, geen idee hoe snel de nieuwere PI's opstarten.

NB stroomverbruik is ook nog een dingetje natuurlijk.

---

Vraag: ik heb in mijn nieuwe versie van mijn fietscomputer nu ook een cadanssensor. Nu laat ik het resultaat direct zien in het display. Maar wat is nog meer interessant om daarmee te doen?

Wat mij opvalt is dat ik op een relaxte tocht best vaak momenten heb waar mijn trappers stil staan (heuveltje af, kruising in aantocht dus maar lekker even uitrijden, etc). Voor mijn gevoel veel vaker dan met een zitfiets.

(06-Aug-2024, 08:00 PM)JanBurp schreef: Maar wat is nog meer interessant om daarmee te doen?

Berekenen in welke versnelling je rijdt. 

De totale actieve tijd bepalen dat je aan het trappen bent.

Advies geven van omhoog of omlaag te schakelen.

(06-Aug-2024, 08:33 PM)Hardloper schreef: Berekenen in welke versnelling je rijdt. 

Dat is een leuke inderdaad. En handig in het donker als ik de stand van mijn versnellingshandels niet goed meer kan zien. Voorzover ik weet heb ik voor die berekening de snelheid nodig, de verhouding daarmee tot de versnellingen in relatie tot de cadans. En een lijstje met de tandwielen en hun verhoudingen. Mis ik nog iets?

(06-Aug-2024, 08:33 PM)Hardloper schreef: De totale actieve tijd bepalen dat je aan het trappen bent.

Dat is ook een leuke, en dan vergelijken met andere dagen of ik minder of meer trap.

(06-Aug-2024, 08:33 PM)Hardloper schreef: Advies geven van omhoog of omlaag te schakelen.

En dan ergens kunnen instellen wat een goede range is (80-100 rpm oid)? Op zich 'voel' ik dat wel aan mijn benen ;-)