Search results for:

Cool thanks. I was thinking of trying to use this antenna:

https://www.mouser.com/ProductDetail/Taoglas/FXR05A?qs=sGAEpiMZZMuBTKBKvsBmlEY7deXXZu90agKoWShIJNEIRe76Xn%2Ffzw%3D%3D

In the PDF you linked, it shows two capacitors (C19 and C21), one for each wire. I can't find what capacitance is needed. Do you know if I even need C19 and C21 when using an antenna like what I linked above?

Thanks for all of your helpful responses, Robin.

Can anyone point me to info on how to best add an NFC antenna to the MDBT42Q Breakout board?

Were you originally planning to make the (tx,rx) version of that call available more broadly? (which would be handy, by the way). I'm just wondering how to interpret that note in the capSense API ref saying:

"Note: This is only available in NRF52 devices (like Puck.js, Pixl.js and MDBT42Q)"...

It seems that Puck.capSense() is the way to go. By the way, how do you access Puck.capSense(tx,rx) on MDBT42Q?

The documentation says "Note: This is only available in NRF52 devices (like Puck.js, Pixl.js and MDBT42Q)", but when I try to call Puck.capSense on an MDBT42Q breakout, the IDE complains that "Puck" is not defined...

Nice!

As far as moving the UART over to a different pin and getting better results, I'm wondering if it's related to an issue I was having where the console was taking over to the USART1 pins on the Puck when I disconnected from the IDE. Basically the same as this troubleshooting post:

http://www.espruino.com/Troubleshooting#console

Except instead of calling USB.setConsole(), for me the fix was to call:

Bluetooth.setConsole(true);

I did this both on the init event, and at the top of my code, and it addressed the issues I was having where it looked like console activity was appearing on my serial connection when I connected and disconnected from bluetooth. This allowed me to interact with a UART device on the tx,rx lines...

Gordon or others, please correct me if I'm wrong here, but if this is correct, it might be worth it to add bluetooth related info to that troubleshooting page.

The update button in chrome://extensions/ did the trick. Now on 0.70.3. Thanks!

Interesting note: This version of the chrome app now says its name is "Default bleoifhkdalbjfbobjackfdifdneehpo.app", whereas the version I had before said "Espruino Web IDE.app". Not a big deal...

@Gordon, I have a bunch of the same devices and so grabbed the board info from the one I switched over to after the other stopped working.

Rebooted IDE. I'm still on 0.69.1 though... Maybe I should reinstall the Chrome app...

Low Battery! I should have thought of that. Maybe low battery also caused the file loading glitch in the first place?... With charged LiPo, the board is working well again. These boards are awesome. Everytime I think I've bricked one, it comes back to life. I've never experienced this level of robustness on other platforms...

Thanks!

Hi @Robin, good call. Thanks. Here's that info:

Chrome App version of IDE (0.69.1) on Mac
Espruino version:
VERSION 1v99
GIT_COMMIT f0d66ba
BOARD MDBT42Q
FLASH 524288
RAM 65536
SERIAL 38d11204-ee97e646
CONSOLE Bluetooth
MODULES Flash,Storage,net,dgram,http,NetworkJS,crypto,neopixel
EXPTR 536882348

Size of code: Was relatively small. Just a few functions I was testing from a larger project.

An error occurred when uploading code direct to flash with the IDE, and now my MDBT42Q Breakout is not working correctly. I can connect to it with the IDE, but a red error rect comes up in the bottom right of the IDE saying it can't get board info, and the REPL is not responsive. I figured I'd try a hard reset, as I've had work on the Puck, but I don't see instructions how to do a hard reset specific to the MDBT42Q. I've tried the following:

1) Remove power. Press and hold BTN. Apply power. Keep pressing until red LED1 turns off.
~~This didn't result in any different behavior in the IDE from what I described in the opening paragraph.
2) Remove power. Press and hold BTN. Apply power. Keep pressing BTN for 20 sec.
~~Same as above
3) I tried to reload the firmware by putting it into firmware mode (hold BTN upon power and immediately release, red LED1 stays on). This indeed sets the device name to DfuTarg, but the nRF Connect app isn't able to connect. If I try to pair with my phone, it connects but then immediately disconnects DfuTarg.

Anything else I can try?

Does the Espruino implementation of RegEx support the | "or" operator?

Simplest test case:

var p = /a|b/;
p.test("a");

Here I'm getting back false... [MDBT42Q 1v99]

Ah, makes sense!

The API Ref page currently states:

power - Transmit power. Accepted values are -40, -30, -20, -16, -12, -8, -4, 0, and 4 dBm. Others will give an error code.

But I tried to set my puck's TxPower to -30 and got this:

>NRF.setTxPower(-30);
Uncaught Error: Got BLE error 0x7 (INVALID_PARAM)
 at line 1 col 19
NRF.setTxPower(-30);

Digging into the code there is a comment indicating-30 is nRF51 only. Might be good to use the same (or similar) line on the API reference page:

Accepted values are -40(nRF52 only), -30(nRF51 only), -20, -16, -12, -8, -4, 0, and 4 dBm. Others will give an error code.

Also, I'm not even sure what is the difference between nRF52 and nRF51? Is nRF52 just newer firmware/hardware?

I also had trouble flashing the ESP8266 from firmware "0018000902-AI03" to "0.25.0.0". I was using esptool on a mac, and it would look like it was working and get to "Uploading stub...", then it would fail with error "A fatal error occurred: Timed out waiting for packet header".

I tried many things, and finally got it to work by decreasing the baud rate from 9600 down to 57600.

For others experiencing this problem, the steps below worked for me:

1) Pin connections:
[ESP8266 ---> USB-TTL adaptor]
GND --> GND
UTXD --> RXD
GPIO2 --> [none]
CH_PD --> 3.3V
GPIO0 --> GND
VCC --> 3.3V
URXD --> TXD

2) Downloaded firmware ESP8266_AT25-SDK112-512k.bin into my Documents folder

3) Downloaded and installed esptool.py using terminal:

cd ~/Documents
git clone https://github.com/themadinventor/esptool.git
cd esptool
sudo python setup.py install

4) In the terminal found my tty port using

ls /dev/tty.*

For me, I found it was /dev/tty.usbserial-AI06B7Y6

5) I then ran the esptool from the terminal:

python esptool/esptool.py -b 57600 -p /dev/tty.usbserial-AI06B7Y6 write_flash 0 ESP8266_AT25-SDK112-512k.bin

It spit out a bunch of stuff and finally finished with:
Hash of data verified.
Leaving...
Hard resetting via RTS pin...

6) To verify, I followed the firmware test in Espruino IDE as described here, and it verified 0.25.0.0.

I'm having success with my hardware SPI clock method. But I agree. It isn't spec friendly. I'll report back when I do larger scale testing in schools and let you know how it holds up to real world use.

I had a need to detect color. There are several boards available to detect color, but none of them work that great. I decided to see if the Puck's built-in red, green and blue LEDs (LED1, LED2, and LED3) could be used to detect color, and it works surprisingly well, so I wanted to share.

Here is the simple approach I tested with:

colors = {};

function learnColor(colorName){
  var ledData = [analogRead(LED1),analogRead(LED2),analogRead(LED3)];
  colors[colorName] = ledData;
}

function whichColor(){
  var closestColor = null;
  var closestLQD = null;
  var ledData = [analogRead(LED1),analogRead(LED2),analogRead(LED3)];
  for(var colorName in colors){
    var colorLEDData = colors[colorName];
    var dr = ledData[0] - colorLEDData[0];
    var dg = ledData[1] - colorLEDData[1];
    var db = ledData[2] - colorLEDData[2];
    var leastSquares = dr*dr+dg*dg+db*db;
    if(closestLQD === null || leastSquares<closestLQD){
      closestColor = colorName;
      closestLQD = leastSquares;
    }
  }
  return closestColor;
}

There is a learnColor() function and a whichColor() function. Press the top of the puck against a color source and call learnColor(colorName) and pass in the name of that color. It works best with back illumination. I'm using my MacBook's screen with the following image:

I went ahead and called learnColor("red") while holding the puck against the red, and then called learnColor("green") against the green, etc..

Now when I hold the the puck against one of the four color patches at random and call whichColor(), it returns the correct color 100% of the time. Pretty cool!

Now, this is VERY primitive at the moment. This is testing the exact same colors I trained on. But, with some additional work, I believe it would be possible to color balance and allow the training to generalize more. Also, currently, retraining on the same colorName will override the old data, but it's possible to average or otherwise accumulate the training data. Many more improvements can obviously be made.

This is just a starting point, but it is already very useful. I'm using it as a UI input device where a young student can hold a puck against different patches on a screen to make different input choices. It's working great at the moment for this purpose.

I should note that to get good readings, it's best to place the top face of the puck consistently flat against the display, and touching the display. I've tried it both with and without the white silicone case. It works better without the case.

Aha! Got the inversion back after trying your technique with hardware SPI.

I reset the board and tried with the following isolated test case:

var spi = SPI1;
spi.setup({miso:D15, mosi:D14, sck:LED1, baud: 1000000});

function testMosi(){
 var finalClk = 0b10000000;
  var c = 0b10101010;
  var d = this.spi.send([c,c,c,c,c,c,finalClk]);
  print(d); 
}

setInterval(testMosi,1000);

Gordon, can you try the above and take a look at D14 on your scope? Do you also see a normally high MOSI line? Please tell me I'm not crazy. Or, at least, show me what I'm doing wrong here...

For what it's worth, here is the version of the module that I'm using. It's the most stable and precise of all the versions I've tested so far. It uses the SPI clock to send 24 ticks, and it uses hardware SPI1, which appears to be twice as fast as software SPI. It doesn't allow changing of the mode, as that requires a nonmultiple of 8 ticks. Here it is:

/**
Options should contain:
{
  sck   : PD_SCK pin
  miso  : DOUT pin
  lsbGrams : grams per LSB
*/
function HX711(options) {
  options = options||{};
  this.sck = options.sck;
  if (!this.sck) throw "Expecting sck";
  this.miso = options.miso;
  if (!this.miso) throw "Expecting miso";
  //this.mode = options.mode||"A128"; //changing the mode isn't supported yet
  this.lsbGrams = options.lsbGrams||1;
  /* The spec sheet specifies sending 24 ticks followed by 1-3 ticks for the gain.
     However, we are using the SPI clock which can only send multiples of 8 ticks.
     The HX711 seems to be fine with only getting 24 ticks.
  */
  this.spi = SPI1;//new SPI(); // use hardware SPI instead of software SPI
  this.spi.setup({miso:this.miso, sck:this.sck, baud: 1000000});
  //this.sck.write(0); // idle, but on
  this.zero = 0;
}

HX711.prototype.readRaw = function() {
    var d = this.spi.send([0,0,0]);
    var val = d[0]*65536 + d[1]*256 + d[2];
    return val;
};
/// Set the current reading to be the zero
HX711.prototype.tare = function() {
  this.zero = this.readRaw();
};
/// Calibrate the lsbGrams value by putting a known weight on the scale
/// then call this function passing in the grams of the known weight.
HX711.prototype.calibrateLSBGrams = function( knownGrams ) {
  if(!this.zero){
    throw "Must call tare() with zero weight first before calibrating.";
  }
  if(!knownGrams){
    throw "Must supply a non-zero value for the known weight in grams.";
  }
  this.lsbGrams = knownGrams/this.readRaw();
};
/// Read the ADC and return the result in grams (based on options.lsbGrams)
HX711.prototype.readGrams = function() {
  return (this.readRaw() - this.zero) * this.lsbGrams;
};
/// Is data ready for retrieval?
HX711.prototype.isReady = function() {
  return !this.miso.read();
};
/// Set whether the ADC is in standby mode or not
HX711.prototype.setStandby = function(isStandby) {
  this.sck.write(isStandby);
};

exports.connect = function(options) {
  return new HX711(options);
};

Below is an example of using it where I call tare() after 1 second and then spit out the weight measurement every second after that. Note that if you tare() too quickly, it'll not be accurate. Sometimes I need to tare again because the zero was off. This appears to be normal behavior since my kitchen scale is the same way (requiring multiple tares to get a stable zero). You can't do reads too close together in time or it'll introduce variability. This might be because the ADC needs to time out since I'm only sending 24 ticks or something... It appears that if you wait at least 30ms between reads, you'll be fine. Here I'm waiting 1000ms:

//var HX711 = require(....)

var h=HX711.connect({
  sck : D14,
  miso : D15,
  lsbGrams : 0.00103123388
});

setInterval(function() {
  if(!h.zero){
    print("tare");
    h.tare();
  }
  else{
    print(h.readGrams());
  }
}, 1000);

Here are some readings with nothing on the scale:

-0.04949922623
0.08559241203
-0.04743675847
0.01237480655
0.00618740327
-0.01753097595
-0.04124935519
-0.00206246775
-0.03918688743
0.025780847
0.04743675847

And here are some sample readings with a 33 gram weight:

33.00773403103
33.00464032939
32.96854714359
32.94998493375
33.00876526491
32.93039149003
33.07167053159
32.96339097419
33.03248364415
33.05620202339
32.95926603867
32.94895369987
32.97060961135

If you round to the nearest 0.1 gram, it's quite stable. Rounding to the nearest quarter gram is extremely stable. Since you can sample every 30ms, one could easily increase sampling rate and return an average over multiple reads to reduce noise even more. That's probably what I'll do for my current application.

Hope this helps others who want to use an HX711.

Gordon, I'm available to investigate things or do tests, or otherwise help in any way.

Yes, I'm using MDBT42Q with 1v99 firmware. I'm using pins D14 and D15. Using D14 for the clock. I just restarted the board by disconnecting the battery and reconnecting. I'm now no longer getting the inverted mosi! I've tried for the last hour to reproduce getting that inversion back, but I haven't been successful yet. Any ideas on how it got into that state? Some internal pullup or something that didn't get reset? It probably would go unnoticed for most SPI situations since during the clock ticks, the voltage is correct. It's just in between the bytes that it goes high. But, after resetting, I'm not able to reproduce. Argh!! If you think that might be a bug somehow, I'm happy to try things that will help track this down if you want me to.

With more testing, I did catch something that I didn't catch before which might be causing the variability in the readings. There appears to be an intermittent variability in the gaps between the mosi bytes. Normally, it's 30uS, but sometimes it's much higher. Here are a couple of examples:

Notice that there can sometimes be over 100uS gaps. Have you run into this with software SPI? These longer gaps seem relatively infrequent. I'm wondering if this is causing the variability in the weight readings due to the ADC timing out or something. I haven't yet been able to correlate these two things though.

Sorry. I feel like this is muddying the water instead of adding clarity.

I've been testing more after changing line 38 in your module from:

var c = 0b10101010;

to:

var c = 0b01010101;

The 2x scale factor is removed and the variability has gone down and it's actually quite good now. If I round to the nearest 0.25 grams, its quite stable, and that's all the resolution I need for my application. I'm thinking it would be fine to release this as a beta version of the module with just line 38 changed. Don't change line 41 to what you had me test. The original ex() function works better.

Cool!

I made your function change, Gordon, but I'm getting pretty much the same results.

I see what you are trying to do with using mosi to send data as clock ticks. However, when I dig into it, it doesn't look to be very "clock like". I hooked it up to a scope, and here's what I'm seeing:

The yellow on the bottom is the actual spi clock (sck), and the cyan on the top is your mosi 0b10101010 data. If you were to scroll rightward along time, you'd see 6 of those 0b10101010 waveforms followed by the finalClk. This image only captures the first two bytes. A few things to note:
1) There appears to be a 30 microsecond spacing between each byte of data transmitted.
2) mosi appears to be normally high between bytes, which appears to result in a very long clock tick between each 0b10101010.
3) Since the mosi signal is normally high, that very first "1" tick probably doesn't count since it was already at 1, and thus didn't go from 0 to 1, which might be why all the bits are shifted over by one resulting in the data reporting back as 2x the actual value. Yup, I just verified this by changing your 0b10101010 to 0b01010101, and the 2x multiplier went away.

You probably have some additional tricks up your sleeve which I'm more than happy to try. In the mean time, If you are okay with it, I'd like to modify your module to use hardware SPI1, and to use the actual SPI clock to send the 24 ticks. It seems to work great even though, as you say, the data sheet doesn't specify what 24 clocks does. It also doesn't allow one to change the gain, etc., but it's very stable and seems to work really well with whatever gain 24 clocks is resulting in...

For some reason, your module has the variability issue that I first ran into and was trying to fix. Although, to be fair, your module's variability is not that bad, and probably acceptable, but my implementation gets better results and I'm not sure why.

I did a simple test. I ran the code and let it sit for several seconds, then placed a 28g weight on the load cell. I captured a screenshot comparing both your module and my original code:

Note the high variability on the left and the low variability on the right. Also, the multiplier is the same 0.00103123388 for both, so it's interesting that the module says the 28g weight is twice as much (56g). That might be a clue as to what is going on?

I also noticed that I'm sending a string of 1's ([0b11111111,0b11111111,0b11111111]), but in your module, you added zeros between the ones ([0b10101010,0b10101010,0b10101010,0b10101010,0b10101010,,0b10101010]), and added the finalClk at the end as well. The other difference is software vs hardware SPI.

Gordon, let me know what I can do to help get this to the end zone of a nice working module.

Hi Gordon, a module would be fantastic! Your modules are so nicely designed and their plug-and-play nature really saves a developer like me lots of time and headache, making the espruino such a great platform to build on.

After reading this thread I almost didn't even bother to try to use an HX711 with espruino, but I somehow decided to give it a go anyway, and I'm glad I did. It is possible to get nice stable and accurate (and precise!) readings from an HX711 chip and a load cell using espruino.
I'm using the MDBT42Q breakout board powered by a 9V battery. When powered by a CR2032, my board would flash red, which I'm assuming means it couldn't supply enough current.

I'm using a shielded HX711 breakout board (from Amazon: http://a.co/ge0HhQR) and a balanced 4-wire load cell.

I'm connecting the standard Red,Black,Green,White wires from the load cell to the board pins like this:

Red --> "Out+" (that's how it's labeled on this particular board)
White --> A-
Green --> A+
Black --> GND

From the board to the espruino, I have the following connections:
VCC --> 3.3
DO/RX --> D15
CLK/TX --> D14
GND --> GND

Here is the code I'm using:

var gain_grams = 0.00103123388;
var zero = 162050;

var s = SPI1;
s.setup({ miso : D15, sck : D14, baud: 1000000 });

var lastReadTime = 0;

function readRaw(){
    var d = s.send([0b11111111,0b11111111,0b11111111]);
    var val = d[0]*65536 + d[1]*256 + d[0];
    lastReadTime = Date.now();
    return val;
}

function tare(){
    zero = readRaw(); 
}

function readGrams(){
    return (readRaw()-zero)*gain_grams; 
}

I get the same accuracy and better precision than my cheap store-bought digital kitchen scale. I'm getting about 0.1g precision reliably.

Note that as long as I wait a while between reads, I get very consistent values back. If I do multiple reads one after the other without waiting in between, then I get high variability. I don't know why that is. Earlier in this forum thread there was talk about needing to follow the 24 pulses with 1-3 pulses for selecting the gain level, but that was problematic for me, as it caused erroneous readings when I tried that. Maybe I didn't do it right. But for my needs, with a simple wait between reads, I'm getting great results. I currently force it to wait 1 second between reads, which is more than enough, and not too slow of a sample rate for my application.