-
• #27
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...
-
• #28
Ahh - yes, you're right. This looks like it's actually to do with the nRF52's SPI hardware!
It seems that data is output MSB first, as you'd expect. However after outputting all data the state of the output line returns to the state that was in the top bit! So I guess either we'd have to move to
0b01010101
orob01100110
(and then double the number of bytes).At this point I think it's probably best to just go with your method and drive it with 24 bits of data despite what the datasheet says. If it's not going to cause any trouble and it works reliably :)
-
• #29
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.
-
• #30
Hey guys! Were you able to get any more progress on this? I'm currently working with a HX711 also, connected to an NodeMCU ESP8266 and I'm just starting in this. I have used both of your modules and getting different results from both. For a 177g object I'm getting around 70g readings but if I lift it I get zero so it seems to be calibrated but the calibration factor is off or something like that.
Thanks in advance! :)
-
• #31
Did some test with HX711 module and PuckJS running 2v08.82
https://github.com/espruino/EspruinoDocs/blob/master/devices/HX711.js
Added an overview and detail screenshot for a
scale.readRaw()
using the HX711.js module.Does that HX711 return look correct?
2 Attachments
-
• #32
Question: Is there a fix to eliminate the pause between sending the next byte?
-
• #33
It might help if you changed
this.spi.send([c,c,c,c,c,c,finalClk]);
tothis.spi.send(new Uint8Array([c,c,c,c,c,c,finalClk]));
? -
• #34
this.spi.send(new Uint8Array([c,c,c,c,c,c,finalClk]));
It does - Thanks!
Now there are 25 pulses for "A128" without any delays in between and pulse width is valid compared to the datasheet
2 Attachments
-
• #35
First approach to tare a scale with multiple calls and median filter.
var SCK = D23, DOUT = D24; scale = require('HX711').connect({ sck: SCK, miso: DOUT, }); function filterMedian(values) { var samples = values.length, median; var i = Math.floor(samples / 2); values.sort(function(a, b) { return a - b; }); if (samples % 2) { //even median = (values[i] + values[i + 1]) / 2; } else { // odd median = values[i]; } return median; } function scaleTare(samples, scale, cb) { var values = new Array(samples); var tare = function(x) { if (!scale.miso.read()) values[x] = scale.readRaw(); if (++x === samples) { scale.zero = filterMedian(values); cb(); } }; function setIntervalX(samples, delay, cb) { var x = 0; var id = setInterval(function() { cb(x); if (++x === samples) { clearInterval(id); } }, delay); } // 100ms deleay is needed when HX711 is in 10Hz mode to read another value // maybe add sps value to options like sps:10 = 100ms, sps:80 = 12,5ms setIntervalX(samples, 100, tare); } setTimeout(() => { scaleTare(10, scale, () => { console.log("scale is now tared"); }); }, 1E3);
Any hints and tweaks are welcome.
-
• #36
Looks good!
Thanks! I have no idea what caused the inversion. There is code in Espruino to handle inversion in software, but it reads whether to do the inversion from flash, so that shouldn't ever be able to get modified.
That 120uS pause would definitely cause the instability - unfortunately it's very difficult to avoid with software SPI since the Bluetooth stack needs to be able to interrupt things to keep the Bluetooth timing correct and keep the connection up.
Do you think you'd be able to keep the code I'd used with the 0b10101010 and try it with hardware SPI?