Meerdere draadloze sensoren voor een Arduino

Ik ben op zoek naar ideeën om 12 sensoren draadloos op een Arduino aan te sluiten. De sensoren zullen ongeveer 10ft van de Arduino zijn. Ze moeten één byte aan gegevens elke 100ms-250ms naar de Arduino sturen op een georganiseerde manier.

  • Ik heb MQTT en pubsubclient onderzocht, maar ik heb geen manier gevonden om van een Arduino een makelaar te maken en er is mij verteld dat deze erg inefficiënt is voor mijn toepassing.
  • Ik heb NRF24L01 bekeken, maar het lijkt te zijn beperkt tot slechts 6 buizen om gegevens op een georganiseerde manier te ontvangen.
  • Ik heb Xbee onderzocht, maar er is mij verteld dat het de datasnelheid niet kan bijhouden.

Andere suggesties worden op prijs gesteld ... Bedankt.

 1
toegevoegd
Bekeken: 37
de bron
ro ru fr es pt de hi bn ar kk tr
Je kunt het doen met een NRF24L01 met slechts een enkele pijp. Het eenvoudigste is waarschijnlijk om actief naar elk knooppunt te zoeken voor gegevens door een knooppuntnummer op te nemen in het querypakket, maar u kunt ze ook laten identificeren met een knooppuntnummer, verzenden met enigszins gevarieerde of willekeurige intervallen en misschien een leesnummer in elk pakket, zodat ze elke meting meer dan eens kunnen verzenden om in het algemeen elke botsing op te vangen bij gelegenheden waarbij de transmissies van twee elkaar overlappen.
toegevoegd de auteur rossp, de bron
Chris, zou je toevallig een Arduino-code hebben om dit te doen, of een aanwijzer naar een referentie, die zowel de client- als de serverzijde laat zien? Dit klinkt alsof het de eenvoudigste oplossing is ... Ik heb in mijn originele bericht niet specifiek vermeld dat elke sensor rechtstreeks op een Arduino is aangesloten. Dank je!
toegevoegd de auteur Ant's, de bron
Heb je de dingen gedaan? Ik ben op zoek naar - hoe ontvang ik draadloze gegevens van vier sensoren met een gegevenssnelheid van 512 Hz (voor elke sensor en tegelijkertijd)? dank je.
toegevoegd de auteur tarastar42, de bron

3 antwoord

Ik zou de nRF24L01 aanbevelen.

Je hebt niet één pijp per knoop nodig - slechts één pijp.

Elke pijp is in feite een adres waarop een knoop reageert: met meerdere leidingen kun je meerdere adressen op één knooppunt hebben (zoals aliassen) - maar je hebt natuurlijk maar één adres per knoop nodig, en dus één pijp per knooppunt.

Het bereik is meer dan voldoende (met de antenneversie die ik honderden meters heb kunnen krijgen geen probleem) en de prijs is zo laag dat het verwaarloosbaar is.

2
toegevoegd
de bron

Het is misschien het gemakkelijkst om een ​​UDP-pakket via WiFi te verzenden. Er is geen extra pakketoverhead voor dit "verbindingloze" protocol: nee OPEN, geen ACK/NAK, geen SLUITEN, enz. De incrementele kosten voor extra bytes zijn erg klein, dus als je beslist, moet je 2 bytes of zelfs 100 sturen bytes, dit heeft geen grote invloed op de doorvoer.

Als je de bytes kunt "batchen", zou dat nog beter zijn. Kunt u bijvoorbeeld 8 bytes per knoop verzenden, eens in de 800ms-2000ms? Als dat niet het geval is, moet met WiFi-snelheden het UDP-pakket met enkele byte zonder veel latentie doorkomen. Weet jij wat de latency is die de ontvanger kan verwerken? Afhankelijk van de toegangstijd tot het netwerk (d.w.z. hoe lang het duurt voordat u de lucht in springt) krijgt u mogelijk een lagere lat met batched-pakketten.

Een roll-eigen benadering zou zijn om een ​​onbewerkte RF-zender/ontvanger te gebruiken met iets als VirtualWire. Met de juiste synchronisatie van de "master", zouden de slaves elk hun eigen tijdslot kunnen hebben, waardoor botsingen worden voorkomen (waardoor de toegangstijd tot het netwerk laag blijft)

1
toegevoegd
de bron
WIFI gaat veel register-met-het-toegangspunttype-instellingen toevoegen voordat je dat kunt doen. Waarschijnlijk zou de reden om dit te overwegen geen inherente voordelen zijn (het is nogal nadelig in vergelijking met de alternatieven) maar de gemakkelijke en goedkope beschikbaarheid van ESP8266-kaarten als sensorknooppunten waarop de poster Arduino-achtige firmware kan uitvoeren. Het kan ook functioneren als de sensorhub en indien nodig de AP - in samenwerking met de bestaande Arduino of mogelijk ter vervanging.
toegevoegd de auteur rossp, de bron

Gebruik nRF24L01. Om botsingen te voorkomen, kun je de sensoren bevragen (zoals Chris suggereerde in opmerking). De opzet zou zijn: Elke sensor zou een uniek adres hebben. De centrale eenheid zou het verzoek verzenden en het sensorknooppunt zou daarop reageren. Centrale eenheid zou een ander adres hebben en alle sensoren zouden naar dat adres zenden. U kunt ook data in ack gebruiken om respons in te pakken.

  • Central node (Addr0) -> Sensor 1 (Addr1): Request
  • Sensor 1 (Addr1) -> Central node (Addr0): Response, sensor data
  • Central node (Addr0) -> Sensor 2 (Addr2): Request
  • Sensor 2 (Addr2) -> Central node (Addr0): Response, sensor data
  • Central node (Addr0) -> Sensor 3 (Addr3): Request
  • Sensor 3 (Addr3) -> Central node (Addr0): Response, sensor data
  • ...
1
toegevoegd
de bron
Het enige wat hier gebeurt, is een-op-een communicatie, het is alleen dat de hub op zijn beurt zo'n uitwisseling heeft met elk knooppunt. Een ding waar je over moet nadenken, is hoe lang je moet wachten op een antwoord, voordat je verdergaat om het volgende knooppunt te proberen.
toegevoegd de auteur rossp, de bron
Er zal voldoende tijd zijn, het is meer een kwestie van wat de beste strategie is om het te gebruiken.
toegevoegd de auteur rossp, de bron
Nogmaals bedankt allemaal Ik ben gewoon comfortabel aan het worden met het programmeren van de Arduino. Zou je een link of voorbeeld Arduino-code hebben om dit te doen? Alle voorbeelden die ik heb gevonden laten een een-op-een communicatie zien.
toegevoegd de auteur Ant's, de bron
Ahh ... begrepen. Wat voor soort vertraging/wachttijd zou typerend zijn? Kan ik zelfs mijn datasnelheid van 250ms halen? Dat wil zeggen, binnen 250ms zou ik een meting van alle 12 sensoren moeten krijgen ...
toegevoegd de auteur Ant's, de bron
Dus hoe de sensor aan te sluiten? rechtstreeks via I2C naar de nRF24L01 transceiver, met een andere transceiver aan het einde van de microcontroller? Zou je aan elk uiteinde geen microcontroller nodig hebben?
toegevoegd de auteur brianlmerritt, de bron