Avatar for AkosLukacs


Member since Dec 2015 • Last active Jun 2019
  • 10 conversations

Most recent activity

  • in ESP8266
    Avatar for AkosLukacs

    The poison part meant to be slight joke.
    In most languages a delay / wait literally waits at that point, and nothing else can happen simultaneously. This leads to locked-up UIs & CPUs sitting and waiting later. More and more languages include some form of async-await, or already have Future / Promise / Task to help avoid blocking code and callback hell.

    If you do that with async-await, it won't block the CPU, it 's just a state machine, that gives the illusion of "sync" code. While allowing the CPU can do whatever it wants. Execute other code, or go to sleep to save energy.

    Ok, that's really far from a kid just learning programming, and I have no experience teaching kids. So you are right, it should be as simple as possible.
    If someone has never seen programming, I guess the concept of a while loop is something new as well.
    Can you get to the same end result with run code every X seconds block?
    For example: can you easily blink 2 LEDs at different frequency? Have never played with Blockly & Espruino, but I think that would need two "timer" blocks, and pretty much done. It would be much difficult in a while loop.
    For interaction (UIs with buttons & leds, or some external chip) an event-driven approach feels better. Honestly, don't know which one would be more easier for kids to grasp. I started with Pascal & C in the school, for and while loops, etc. Those languages don't support async. But what if a kid can start with a language that has async support?

  • in ESP8266
    Avatar for AkosLukacs

    The nodeMCU resets, because the ESP8266 has a watchdog, and the while loop prevents control returning to the underlying Espressif OS. But I'm pretty sure it would mess up USB and Bluetooth communications as well. Also, even a simple uart buffer - that uses HW uart & buffer - could overflow in a couple of seconds.

    Almost wrote that there could be a "main loop a'la arduino" thing in Espruino-Blockly, that emulates the expected behaviour. But the purist inside me thinks that kids mind should not contaminated be by seeing a blocking wait call on a microcontroller. Or actually in any code. Even if everybody seem to do that.
    Did you know that god kills a kitten when you use blocking wait in any code? :O

    Instead if the while(true) block, you can use the run code every X seconds block I guess.

  • in ESP8266
    Avatar for AkosLukacs

    AFAIK, on the ESP8266, only some pins are truly general purpose input and output pins. Lots have restrictions either during boot, or don't behave nicely either as input or output. Nodemcu.D8 == GPIO15 might be one of those pins, but not certain about it...

  • in ESP8266
    Avatar for AkosLukacs

    Looks like the RMF96 and SX12xx modules have different parameters. The RFM69's connect's first parameter should be the SPI object, not an object with an spi property:

    // from the docs:
    rfm = require("RFM69").connect(SPI2, {cs:B10, rst:B1, freq:434}, ...
    // your code:
    rfm = require("RFM69").connect({spi:SPI, cs:D8, freq:915}, ...
  • in Puck.js, Pixl.js and MDBT42
    Avatar for AkosLukacs

    Just quickly looking at the datasheet:
    Do you set CS to high?
    Is your wiring good?
    Is the I2C address correct?

    For example, have a bunch of INA226 modules that don't use the default I2C address, and SDA and SCL markings on the breakout board are swapped...

  • in Projects
    Avatar for AkosLukacs

    One thing you may try: try to put it into bootloader mode with the DSD6 app. Absolutely no idea whether that clears the watchdog, or what might happen, but may work. Probably wait for you watchdog timeout, before trying to reflash, so it doesn't restart the watch while flashing, and bricks it even more :)

  • in Tutorials
    Avatar for AkosLukacs

    Suggestion: bold Post your code :)
    Another suggestion: highlight the part you feel relevant, but post a full reproduction. There may be a mistake at initialization, or even unrelated parts could interfere.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for AkosLukacs

    If you have an android phone, get nRF Connect by Nordic Semi, and watch the RSSI graph as you walk around. I think it's worth to get an idea what to expect. Was using nRF connect just yesterday to test the range of BLE things.
    Of course you can do this with NRF.findDevices or NRF.setScan, just nRF Connect gives you a graph in a couple of seconds.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for AkosLukacs

    I would say it's not trivial.
    Depending on you environment, all kinds of things can affect the signal strength, not just range and TX power: orientation, objects, walls, people in the room.
    Probably you should start recording range and RSSI values, and if it's consistent, do some interpolation (maybe even just use excel, and pick one distance value for every 10 dBm difference)

  • in Porting to new Devices
    Avatar for AkosLukacs

    Oh, that's impressive. NINA B3 on both sides? What antenna did you use?