-
I tried with the "connection.setUsed()" commented out, but that made no difference.
Will rewire my lab setup later tonight and se what happens if I make it silent.
-
Yes it is always printing data to the console :-)
The module polls a device over a serial port, but I need to modify the code to not print any errors when I lift the TX pin on the device. Normally it would print an error every time it timeouts.
I have previously tried using the tx function in EspruinoHub to write data to a device via mqtt, I'm guessing that function will be effected by this to?? Never got it to work...
-
I just installed EspruinoHub on a Raspberry Pi 4 with node-red and an external BLE dongle with an external antenna. hciconfig shows the dongle ok.
The config for EspruinoHub points mqtt to a separate machine that only runs a mosquitto.
The web pages works fine, I can see advertisement etc etc. Ok.
Using an mqtt sub app I can see the /ble/# messages. Ok.
I start the webIDE, and it shows me the Espruino devices. Ok.
Click on a device and it connects and I can interact with the device. Ok.
Looking at the /ble/# topic on the mqtt server I get all devices messages before starting the webIDE, when the webIDE starts I only get the connected device messages. Ok.
I then click the disconnect icon, and the webIDE says disconnected :mac:. Ok.
But, looking att the /ble/# subscription I'm still getting the console messages from that device.
To get espruinoHub back to it's original state I need to stop and start it.
To me it looks like the disconnect is missed when the webIDE closes. -
Sometimes one has to ask the question to realise the simple answer... It's an electricity meter I'm talking to as well, and yes the easy way is to just hard code the query :-)
But it might be good to check the CRC on the reply. -
How did you sort out the CRC calculation??
Thats the only part that can be a bit tricky for a simple modbus implementation, I can build the packet by hand and parse the response my self.
I often get devices scattered all over the place that has a RS485 port with modbus, often its just a few bytes of data that I want from it. But running a hardwire etc etc to this makes it a lot of work. A small BLE device that polls data and sends it as BLE manufacture data would be perfect to just get the status and monitor the device values. WiFi is often hard to get working, and BLE actually has longer range in real life :-) Being able to reprogram the device wireless makes it just perfect.
-
I'm thinking of using a MDBT42Q module to poll data from a Modbus device over RS485.
My hardware will use the MAX13487 that implements auto tx/rx switch, I have used this in many designs before and it works just fine with modbus. So no need for TX control pin.
I found this, https://github.com/makejs/modbusTCP-Espruino, but cant make out if its just a clone of modbus-serial or if it's actually for Espruino.. anyone?
-
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. -
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... :-)
-
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.
-
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.
-
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 :-)
-
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.
-
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?
-
Thank you for that, I re read that page and I'm starting to get to grips with how the device works.
I moved everything in the E.on to just after all the functions, this seam to be a better way of doing it. -
So I might have solved this one.
If I do a reset() before doing an upload to flash in the webIDE it always seam to work. -
Tried it, this is the output..
>require("Storage").eraseAll() =undefined Uncaught SyntaxError: Got [ERASED] expected EOF at line 1 col 1 [ERASED]... ^ in function called from system Uncaught SyntaxError: Got [ERASED] expected EOF at line 1 col 1 [ERASED]... ^ in function called from system Uncaught SyntaxError: Got [ERASED] expected EOF at line 1 col 1 [ERASED]... ^
And it goes on and on like that.
-
The MDBT42Q module is connected to a device via the usart pins, this device keeps sending data in a cyclic manner. Part of my project is to parse that cyclic data.
The other part is that I at an intervall has to send a string to the device to make it print extra info.
I have now added code for sending the string when the button is pushed, and at an intervall. Both events work fine, the function print a message on the console just before the string is sent on the serial port.But, every now and then the device just stops sending on the serial port. There it nothing on the pin. I have an analyzer connected on the same pin so I know that it's silent.
This tends to happen after an upload, and then it stays in this state for X amounts of uploads and or reboots. I have still not found a way to trigger it or to fix it, its random at the moment.
I have also noticed the console sometimes jumps back to the serial port, even though it should not. This can be a problem as the espruino tries to interpret data not ment for it... The console should always be bluetooth as the serial port will always be connected to the device.
I have attached the code, please mind this is just a scratch testing thing to get to grips with the device and test what and how to do this.... :-)
-
First of it turns out the webIDE had gotten it self in some state, closing the browser and opening it again allowed me to connect and get a prompt, at least long enough to run reset() to clear out the bad code.
So at least one of the modules are now running again, will check on the other one later.I have now installed the chrome app, and that seam to be more stable and works better.
-
So, after a lot of debugging I have now realised how the "Flash (always)" works and what a "reset()" actually means. It's not a reset or reboot, it's a system clear. And my broken code is now written with "Flash (always)" so my two dev modules are now bricked.
So how do I get them back? A DFU update does nothing.
Is there any other way to program the module and clear the flash??? -
Adding the Serial1.setup to the init section seam to work. Thank you
-
I have a project where the MDBT42Q module will listen to a serial port and parse the data, due to this the state of the RX pin can be either gnd or 3v3 depending on whats on the line when starting. There is no way to make sure that the pin is high when the MDBT42Q module starts.
So is there a way to change this behaviour?
Can it be done from the JS code?
Or can it be done by doing a new FW where this test is removed?
Espruino
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
So a bit more testing done.
I changed my js code so that is dont print anything to the console by it self. So when connecting with the IDE it's silent.
I run EspruinoHub stock, line 423 is active in connect.js.
It starts, finds the devices, updates the mqtt with all the data.
I have enabled all the mqtt options so there is a stream of messages at /ble/# that i subscribe to.
I open the IDE from EspruinoHub, and I can connect to my device. Press enter a few times and I can see the packets on the console from start.sh.
Press disconnect.
After som time the console states "Connection [] IDLE"
But there is no stream of messages on the MQTT, all silent.
The clock is ticking over on the console output from start.sh, but the list of devices does not update.
And reloading the IDE and pressing connect does not show any devices to connect to.