Avatar for JohanWinas


Member since Sep 2020 • Last active Sep 2020
  • 5 conversations

Most recent activity

  • Avatar for JohanWinas

    As I said in my first reply, this is not an issue any more as the DFU app has found a way to work around how iOS it self and other iOS apps normally shows devices, as long as you operate the app the correct way.
    I was just a bit to quick to post a suggestion based on my previous experience, not having used the nRF-Connect app to any extent before.

  • Avatar for JohanWinas

    It's fine when you have several units with the same name, they have different mac addresses, like fitness devices etc etc. For normal use this is not a problem, the app will talk to the mac and not the name etc etc.

    The problem with the cache is during development and programming, if a device changes it name from the default to the production name iOS then shows the old name instead of the new name as the cache is not updated, after some time it does change over.

    The same kind of problem happens when starting new units that have the same name, as I did yesterday where all the units show up as DFUtag, but with new mac addresses one after another, within iOS it self there is no way to tell them apart and apps like LightBlue struggles with this as they try to connect by getting the mac from the cache based on the name.

    Now Nordic has managed to go around this byt doing a refresh, not stop/start of scanner or stop/start of the app, but swiping down, this makes the new device show up at the top and the icon is in a different colour the the last unit.
    Using for example the LightBlue app this is a problem, I have had units that come from the supplier with the same name for all modules, when I am done with one unit and are moving on to the next it is a hassle to get iOS to go for the new module instead of the previous.

    Somehow Nordic has found a way around this, so will have a look if they published the code for the DFU app and I can show that to our iOS developers on how to force iOS to do a refresh or how to go around the cache issue.

    Changing services have the same issues, it's cached and the cache has to expire to read the new data. To "force" this a restart of the bluetooth helps, but not always. Can be a pain during development as you don't see whats there but what was there... :-)

  • Avatar for JohanWinas

    The web dfu looks very interesting, will have a look at that.

    I was a bit quick with my post, as it turns out Nordic has done something "out of the ordinary" with the app, you swipe down to refresh the list it manages to clear the cached data and shows the new device and new device names. This is something we have had issues with in other apps and with other developers. The same problem happens when a device change its name, the old name is shown for a long time in iOS as it is in the cache.

  • Avatar for JohanWinas

    I just ran into a funny problem.
    I need to upgrade 23 MDBT42Q modules to the latest FW, and since I have already packaged them I have no other option than to use DFU, and I use iOS...
    So since all the modules have the same name, iOS remembers the mac, so for each device I have to go into settings of iOS and turn of bluetooth, and then activate it. Or the app will try and talk to the last devices mac adress as it caches this...

    Having the module present itself with a name that includes part of the mac would solve this.

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

    I moved the serial connection to D14 and D15, everything works OK now.

    I read the page about pins for the serial port and must have mixed up pages as my memory said it could not be moved....

    Thank you very much for the help :-)

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

    I always use the "save to flash".
    And before every upload I run "require("Storage").eraseAll();reset()" to clear the board.

    The reason I run "require("Storage").eraseAll();reset()" before every upload is that uploads have a tendency to fail half way if not. I am guessing the BLE update instruction running every 2s might interrupt the BLE transfers??

    I removed the "Attempt to clear" section and re did the same tests. No change, still cant have the RX pin connected.

    Just to point out. The status of the TX pin on the ESP32 will be unknown if it's transmitting data. During a cold power on this is most likely the case.

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

    I still have a problem with my query not being sent out on the serial port after power on.
    The setup is that I have the MDBT42Q connected to an ESP32 based board, this board has a console on its main serial port where I have to send a command and read the respons.

    I have attached the core running right now.

    Senario1: I power on both the esp32 and the MDBT42Q at the same time, the MDBT42Q gets it 3V3 from the ESP32 board. There is now no query sent. The LED flickers so the timer is running, but there is no bytes coming out of the MDBT42Q module.

    Senario2: I power on the esp32 and leave the MDBT42Q unpowered, this skips load of start up messages etc etc. Have TX and RX connected and connect VCC. Same as Senario1, no query is sent.

    Senario3: I disconnect the RX pin on the MDBT42Q, apply power, wait until one flicker of the LED (one query is send), and then connect the RX pin. The system now runs.

    So I can not have the RX pin connected during boot of MDBT42Q, doing so makes the TX pin silent.

    For senario 1 and 2, if I after power on connect via BLE the console does not show the traffic from the ESP32 board. And sometimes I get "New interpreter error: BUFFER_FULL" on the console just after connecting.

    With senario 3 I get the console messages as expected when connected via BLE.

    Any suggestions?