Navigation

    • Register
    • Login
    • OpenHardware.io
    • Categories
    • Recent
    • Tags
    • Popular
    1. Home
    2. Yveaux
    3. Topics
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    Topics created by Yveaux

    • Yveaux

      Calibrating nRF24 pcb antennas
      General Discussion • • Yveaux  

      1
      5
      Votes
      1
      Posts
      43
      Views

      No one has replied

    • Yveaux

      Windows PopCom tool shows which USB serial ports are available
      General Discussion • • Yveaux  

      10
      7
      Votes
      10
      Posts
      1566
      Views

      mfalkvidd

      @neverdie said in Windows PopCom tool shows which USB serial ports are available: it must be hidden in plain sight Indeed
    • Yveaux

      MySensors booth at Eindhoven Maker Faire!
      Announcements • • Yveaux  

      9
      12
      Votes
      9
      Posts
      3676
      Views

      Dheeraj

      @Yveaux I wish i could come
    • Yveaux

      Upgrade to ATMega328pb
      Hardware • • Yveaux  

      8
      3
      Votes
      8
      Posts
      14249
      Views

      NeverDie

      Great OP. Any updates? I'm frankly surprised that neither sparkfun nor adafruit nor arduino have come out with a board for it. What gives?
    • Yveaux

      Safety first ;-)
      General Discussion • • Yveaux  

      4
      2
      Votes
      4
      Posts
      1344
      Views

      Yveaux

      @Oitzu Hehe! Nope, but both were wrapped in huge antistatic bags, one could camp in
    • Yveaux

      Meetup in the Netherlands - Saturday July 30th, in Breda!
      General Discussion • • Yveaux  

      112
      1
      Votes
      112
      Posts
      28609
      Views

      GertSanders

      @TheoL I will miss the mini maker faire as well (chillin in Ibiza at the moment, familytime)
    • Yveaux

      Use Google Analytics to store and visualize sensor data
      General Discussion • google analytics • • Yveaux  

      9
      1
      Votes
      9
      Posts
      3349
      Views

      Yveaux

      @TheoL said: offtopic: Conrad is vast blij met jou Tabs open hebben staan is een, werkelijk bestellen iets anders
    • Yveaux

      Chinese rubbish.... or is it?
      Hardware • • Yveaux  

      6
      2
      Votes
      6
      Posts
      4361
      Views

      FotoFieber

      @Yveaux said: @FotoFieber yes, I did get it to work with a 3.3v pro mini. But the module you're referring to is not based on the vs1053 mp3 decoder chip, so it has to be controlled differently... Yes, the driver logic is different. But I would be interested, what message types you used. AFAIK there are no matching types defined by the api...
    • Yveaux

      Are we initializing the nRF24L01+ correctly?
      Development • • Yveaux  

      16
      4
      Votes
      16
      Posts
      9432
      Views

      tekka

      @davboecki
    • Yveaux

      ESP8266 WiFi gateway port for MySensors
      Development • • Yveaux  

      328
      14
      Votes
      328
      Posts
      309561
      Views

      mfalkvidd

      @ahmedadelhosni where is gpio15 used? (This is a very long thread so finding it without your help isn't easy)
    • Yveaux

      Extending range of regular nRF24L01+
      Hardware • • Yveaux  

      28
      1
      Votes
      28
      Posts
      25039
      Views

      gohan

      I know but I am not going to waste more time on them
    • Yveaux

      Hacking a wireless weather station display
      My Project • • Yveaux  

      5
      4
      Votes
      5
      Posts
      5788
      Views

      Andy Pep

      well done l33t hack
    • Yveaux

      Ultrasonic wind sensor
      Hardware • • Yveaux  

      6
      0
      Votes
      6
      Posts
      4985
      Views

      Zeph

      It looks like it's just an ultrasonic transducer. With multiple ultrasonic transducers one could create a wind speed and direction sensor. (If you measure N/S wind speed and E/W wind speed you can get total wind speed and direction). The typical cheap distance measuring modules use very cheap 40KHz transducers; these operate at 200 KHz. Wind speed can be measured by timing a pulse between two transducers. The pulse will arrive slightly sooner if the wind is blowing towards the receiver, slightly later if it's blowing the other way, but the differences are small so you have to compensate for other factors like temperature, perhaps air pressure and humidity. With 4 transducers at over $200 even before all your analog circuitry to generate the high voltage drive and sensitive receiver, this is not going to be super cheap!
    • Yveaux

      Beware: FTDI driver update will brick *fake* FTDI USB to serial converters
      Hardware • ftdi driver • • Yveaux  

      21
      0
      Votes
      21
      Posts
      28805
      Views

      masterkenobi

      @hek said: If you have an Uno around your can use that for programming the ProMini. http://www.instructables.com/id/Arduino-Pro-Mini-Stand-Make-It-Reusable/ http://www.instructables.com/id/Uploading-sketch-to-Arduino-Pro-Mini-using-Arduino/ It's weekend and I finally have the time to give this another chance and guess what? It works! I manage to upload the sketch to my Pro Mini and successfully created my first ever MySensors sensor! Thank you so much for that!
    • Yveaux

      Upverter
      Hardware • pcb schematic upverter • • Yveaux  

      1
      0
      Votes
      1
      Posts
      1108
      Views

      No one has replied

    • Yveaux

      MySensors protocol format
      Development • protocol • • Yveaux  

      24
      1
      Votes
      24
      Posts
      13947
      Views

      Zeph

      @Yveaux said: I think we could drop the protocol version number and use a full byte for command type. When, in the future, a command gets extended we can just reserve a new command-number for it. All existing applications will only recognize the old command-number and ignore the new one. As @zeph already pointed out this allows for more efficient usage of the 8 bits and a new version will not immediately disqualify an onld node completely as it will stil listen & respond to old commands. The value of having defined groups of command associated with a given protocol version is that you can get a pretty good idea of what a node will understand (or send). The first approach was to have some fixed number of bits for a protocol id, and some number for command-within-protocol (like 8+8 or 5+3 or whatever). I'm glad you see the advantages of adding command codes sequentially instead, especially if we are using one byte. I was suggesting that a given protocol version define a contiguous range of commands (plus some universal ones at the beginning of the codes). One caveat was that the "current protocol version" would be allowed to add new commands at the end of the sequence - the "last command allowed in this version" doesn't get frozen until a version is superceded by another one. Any given node need only understand the universal commands plus the range corresponding to the protocol version it was written to. So each version has the common universal commands plus a non-overlapping range of command specific to this version. The disadvantage is that you may have to redefine new command codes for commonly needed commands like "set value" every time you move to the next version. So in the first version, command 4 might be set (part of range 3..9). Then in the next version with commands (10..17) we have to define a new "set value" within that range, maybe code 11. Nodes implementing the second version only understand commands 0..2 (universal) and 10..17, they have no need to understand version one commands 3..9. A gateway would not expect a version 2 node to understand command 6. The hub could ask the node for the start and end of the range of commands it can accept. === One variant, which you are suggesting I think, is to ignore versoin based commadn code sub-ranges and just keep all commands allowable to all nodes. This has the advantage that "Set value" command 4 (in the above example) can continue to be used "forever", and not need to be reallocated code 11 to fit within the new version's range. But it may over time cause fragmentation or bloat - either we carry around the code to handle all commands (eg: 1.3 and 1.4 both), or the set of commands allowed once you switch to a new protocol version is non-contiguous (it contains some but not all commands from the older protocol version). I actually considered this, and the possibility of having the node respond to "what commands can you handle" with a bitmap instead of a start and end value, but decided that was getting too complicated. That was just my judgement call tho. (If you can correctly anticpate this kind of command in the "universal commands" that are part of all versions, the issue goes away. In the first appraoch, maybe "set value" is command 2 and globally available, not needing to be allocated a code in each versions's code range) But sometimes your concept changes more than you anticipated and "set value" might need to become a new command type in newer protocols). Deciding among these options depends somewhat on one's philosophy of where configuration information should be stored - in the nodes or in the hub. There are many answers to this question at different granularities. If you accept the concept of storing much config on the hub, then another approach emerges: each node can use a basic common protocol to report on first connecting what version of the full protocol it implements that per-node protocol version is stored in the hub the hub has bitmaps or tables of what command codes work for each protocol version it understands if the hub understands more than one version, it can communicate with nodes using any of those versions In this case, you don't make every packet include an explicit (fixed bits allocated) or implicit (code range) protocol version. But the hub could still know which commands work and don't work for any given node.
    • Yveaux

      OpenHAB/MQTT Tips & Hints
      OpenHAB • • Yveaux  

      40
      0
      Votes
      40
      Posts
      57803
      Views

      Yveaux

      @ericsko sounds to me that you're missing a message instead of the Arduino being too 'slow'. But go ahead, use a single message to send the rgb value and post your findings in here!
    • Yveaux

      RFM73 experience
      Hardware • nrf24l01+ rfm73 • • Yveaux  

      14
      0
      Votes
      14
      Posts
      8589
      Views

      Yveaux

      FYI: RadioHead library 1.34 has some specific initialization code for RFM73 in the nRF24 driver (e.g. ACTIVATE command). See https://github.com/Yveaux/RadioHead/commit/f895ba933950681234d714fd7c3d3c18658b8ed5
    • Yveaux

      Wireless nRF24L01+ sniffer for MySensors
      Development • nrf24l01+ sniffer omg wireshark • • Yveaux  

      108
      5
      Votes
      108
      Posts
      69950
      Views

      apharvey99

      @Yveaux Thanks very much for all your help. I hooked up the IRQ pin to the Arduino pin 2 as you suggested and it’s working fine now.
    • Yveaux

      Anyone else experiencing this?
      Troubleshooting • • Yveaux  

      14
      0
      Votes
      14
      Posts
      4538
      Views

      Zeph

      @Yveaux Anyway, the nRF24 seems to be very sensitive to location/orientation then?! It's true that I just 'throw' it on the table an the orientation will be different eveyday. Is that the right conclusion? Really? See the antenna patterns @a-lurker found in an ap note for a similar meandering inverted F antenna: http://www.ti.com/lit/an/swra117d/swra117d.pdf (scroll down to the polar charts). There are 6 charts with two each (horiz and vertical polarization) for each of the three planes. Our nRF is probably different in detail but similar overall. So just rotating the nRF 20 degree along some axis might well significantly reduce or enhance its antenna gain. This is without any question of reflections or interference.
    • Yveaux

      New library to read Arduino VCC supply level without resistors for battery powered sensor nodes that do not use a voltage regulator but connect directly to the batteries ;-)
      Development • supply vcc • • Yveaux  

      90
      4
      Votes
      90
      Posts
      143266
      Views

      iahim67

      @gohan sorry, my bad, nothing to do with vcc library ... just realized that vcc lib allows me to measure vcc without resistor divider:-)
    • Yveaux

      Variables are ack'ed with messageType M_SET_VARIABLE
      Bug Reports • • Yveaux  

      6
      0
      Votes
      6
      Posts
      2510
      Views

      hek

      Yes, when sending an request you expect and M_ACK answer back from gateway. (This has changed to a SET back in the version I'm working on now).