Search results for:

Above it only needs to be twice the prop diameter.

Below is needs to the best part of 15 times that as the craft produces 7kg of thrust at full power.

While the craft is climbing, the sensors on the mast are in clean air.

Prop wash destroys the pressure readings.

Hi @Arnold

I have the sensor in the little white radiation shield on the top of the mast in this picture.

From lots of flights I worked out the sensor needs to be at least a blade diameter above the plane of the blades. So if you run 12" blades, the mast needs to be at least that otherwise you get bad pressure values.

Also the mast needs to be as light as possible and as stiff as possible. Otherwise you can get lots of nasty pendulum effects which make it impossible to fly.

Let us know how you get on.

Cheers

Ian

Not had any time past week or so @Gordon, been away working. Hope to be home again next week and get back on it.

The program and module code I posted as Gists above is my latest (links below). So if you want to take that and spend some time on it, you are more than welcome. My aim was to eventually replicate what Ian did with his Arduino example.

I just recently got the "Humidity Most Accurate" working as well, so only "Pressure" and "Pressure More Accurate" needs fixing although they look OK comparing my code with Ian's, the data sheet from Bosch and Bosch's code, so suspect a rounding issue or similar.

Current test prog is here
Current module code is here

Output currently looks like this:

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v77 Copyright 2015 G.Williams
>echo(0);
ChipID   : 96
CtrlMeas : 36
Measuring...
.
.
.
.
Done !!!
----------------------------------------------------------
Temperature                      : 21.9
Humidity                         : 45.8583984375
Pressure               (Suspect) : -126.86268593172
----------------------------------------------------------
Pressure More Accurate (Suspect) : 85.15359374999
----------------------------------------------------------
Temperature Most Accurate        : 21.90582997486
Humidity Most Accurate           : 45.85865386029
Pressure Most Accurate           : 1006.10934649366
----------------------------------------------------------
{
  "i2c": {
    "_options": { "scl": B6, "sda": B7, "bitrate": 100000 }
   },
  "compParams": { "dig_T1": 28415, "dig_T2": 26397, "dig_T3": 50, "dig_P1": 37393,
    "dig_P2": -10875, "dig_P3": 3024, "dig_P4": 6654, "dig_P5": 13, "dig_P6": -7,
    "dig_P7": 9900, "dig_P8": -10230, "dig_P9": 4285, "dig_H1": 75, "dig_H2": 356,
    "dig_H3": 0, "dig_H4": 335, "dig_H5": 0, "dig_H6": 30 },
  "t_fine": 112157.84947130654, "adc_t": 524245, "adc_p": 336661, "adc_h": 29806 }
----------------------------------------------------------

Cheers

Ian

Probably not much help, but I have run the main Espruino board, single I2C board for pressure, temp and humidity and NEO6 GPS all logging every second to microSD card for 24 hours (so little sleep) from a 1000mAh 3.7v LiPo with power to spare, though not much.

So assuming you can power down external kit while sleeping, battery requirements won't be huge I would have thought.

@LawrenceGrif I don't know, never used them. Most do have time limits though.

http://www.carphonewarehouse.com/sims/pay-as-you-go/pay-as-you-go-sims most come with call minutes and texts as well but fairly cheap.

GiffGaff do SIM deals with data only and can be topped up or contract starting at £5 for 500mb.

OK, it's all working, sort of...

Couple of the values coming back are suspect but I need to go through each function and check each one to ensure it's doing the right thing. I suspect it is just some rounding issues or other gotchas going from C to JS.

Some output from my test rig:

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v76 Copyright 2015 G.Williams
>echo(0);
ChipID   : 96
CtrlMeas : 36
Measuring...
.
.
.
.
Done !!!
----------------------------------------------------------
{
  "i2c": {
    "_options": { "scl": B6, "sda": B7, "bitrate": 100000 }
   },
  "compParams": { "dig_T1": 28415, "dig_T2": 26397, "dig_T3": 50, "dig_P1": 37393,
    "dig_P2": -10875, "dig_P3": 3024, "dig_P4": 6654, "dig_P5": 13, "dig_P6": -7,
    "dig_P7": 9900, "dig_P8": -10230, "dig_P9": 4285, "dig_H1": 75, "dig_H2": 356,
    "dig_H3": 0, "dig_H4": 335, "dig_H5": 0, "dig_H6": 30 },
  "t_fine": 0, "adc_t": 525584, "adc_p": 335232, "adc_h": 30412 }
----------------------------------------------------------
Temperature                      : 22.33
Humidity                         : 49.2021484375
Pressure               (Suspect) : -124.63193742510
Pressure More Accurate (Suspect) : -116.96609374999
Temperature Most Accurate        : 22.32728913521
Humidity Most Accurate (Suspect) : NaN
Pressure Most Accurate           : 1009.19167457070
----------------------------------------------------------

Current test prog is here
Current module code is here

More when I've had time to work the functions and improve the code a bit. But still happy for anyone to chip in with improvement ideas.

Cheers

Ian

Scratch that, its a C Union statement in the header file that blasts 20 odd values in of various sizes.

Guess I will need to sit down and push them in by hand. Boo. :)

But on the plus side, combine that with what looks like sensible raw values being read, should be workable.

@alexanderbrevig Hey, don't apologise, just happy you made a stab at it to get me started.

I've actually come up against a bit of a showstopper here. I think I'm getting sensible values back from the sensor with a raw read of values. However, I cannot use any of the compensated functions as some values required are simply not set.

Looking at the Arduino code (which I confirmed works just fine on my Arduino Uno this morning) here and look at line 50 for example there is a variable from the compStruct called

compParams.compStruct.dig_T1

and various others of the form dig_Tx and dig_Px (defined in the header file here starting at line 129).

I cannot see anywhere in the Arduino code where these values get set, hence Alexander's code also won't have set them. dig_Hx (Humidity) are set and I am getting a sensible looking humidity value (although not temperature compensated yet)

So can someone who is Arduino fluent take a look at the EA code from @ianharris and tell me where the dig_Tx and dig_Px values get set.

I've been looking at this all day and I'm sure I'm missing something but I just cannot see it.

Cheers

Ian

@alexanderbrevig Board arrived this evening so hooked up to Espruino and got code loaded. Think it was right on flash code limit as was reporting out of memory while loading it. But minifying the module solved that.

Comms over I2C confirmed and can dump out the bme280 object structure and am getting compensation values back from the chip.

Got a few errors:

Line 290

var data[8];

throws an error and I think should be:

var data = [];

Line 380:

this.writeRegister(C.regCtrlMeas, C.ctrlMeas);

I think should be:

this.writeRegister(C.regCtrlMeas, ctrlMeas);

Line 10

regMeasurementsStart: 0xf,

should that be:

regMeasurementsStart: 0xf7,

Will crack on running tests in the morning but for now I'm off to bed.

Cheers

Ian

@alexanderbrevig That's right, but Ian didn't have in UK stock so waiting for delivery from the USA so should be here in the next few days.

As soon as it arrives I'll hook it up to my second, new shiny Espruino (my first is embedded now) and try your code and see where we are. I'll of course report back then and hopefully we can get to the point of a working module.

Hi Ian,

Didn't know you were on here :)

Cheers

Ian

Looks good @alexanderbrevig :)

I'll hopefully receive the breakout board early next week so I can try the module live. I'll report back then once I have it hooked up. (Second Espruino also on the way to become my dev board)

@alexanderbrevig I don't have enough experience for a port myself, although it is something I'm building up to. As always it's finding the time. So if anybody wants to have a go, it would be most welcome. As I said on the other thread, I'd expect the BME series from Bosch is likely to replace the BMP and other series on most breakouts soon and is being touted as the IoT chip of the future.

@Gordon Doing multiple flights is the ultimate goal. In those situations where the weather might go into fog and where the impact is high, e.g. busy airfields, being able to sample every hour, every 15 minutes, or almost continuously could be very useful. As flights typically only take three minutes (depending on altitude), then you would get three or four flights per set of batteries and just keep changing them out/charging as long as you need to fly. It only takes a minute to change the flight batteries out. Once I've settled on a sensor package, and the BME280 looks a likely candidate, I plan to add a 433Mhz radio downlink for live collection and monitoring of the data as it is sampled. Little bit of web browser coding and live graphs will be possible. BME280 will greatly simplify the physical setup as then it will be just the BME280 and a GPS module attached to the Espruino rather than my current setup of BMP180, HIH-4060, MAX31855 + K type TC and GPS which is getting messy. Power usage will also decrease as well. Nice.

On the graphs above, with almost no wind on the first flight, you see these small temperature inversions (temperature actually rising with height) and is what causes air pollution and mist/fog to hang about in a layer just above the ground on cool mornings/low wind days. The second temperature graph as the front is arriving, wind has picked up and has mixed those few hundred feet of atmosphere together giving a much more homogenous atmosphere (and can be seen less obviously in the humidity as well). It's neat to see in action.

Yes, the BME680 also looks interesting with the air quality sensor as well. I've seen a paper by Bosch (but typically cannot find the link) where they have shown they can replace the much larger, heated MQ type specific gas sensors with the MEMS packages soon. That will truly make tiny sensor packages which you can use anywhere. Exciting times. :)

Cheers

Ian

I'm looking to move to a single sensor for packaging reasons and the Bosch BME280 is my first candidate to try on an Embedded Adventures MOD-1022 board. More info and links on another thread here.

Cheers

Ian

...and 15 minutes later when the wind had picked up and first drops of rain were falling.

Some more data from the other day just before a cold front and associated rain band arrived. The data below is from 15 minutes before the rain arrived and was almost windless....

Hi All,

As some of you know, I'm interested in flying sensors on multicopters using the Espruino as the controller board (my project here).

The Bosch BME280 is a three sensor chip (pressure, temperature and humidity) and Embedded Adventures (EA) have made a breakout board for it called the MOD-1022.

EA have also produced an Arduino library for interfacing to the board here on GitHub.

Would those with that kind of knowledge take a look at their library and tell me if its feasible to port to a module for Espruino please? I've had a scan through it and not seen anything I didn't recognise although I'll admit I didn't understand all of it.

These three sensors chips are used more and more in mobile applications and I would expect that they will eventually replace for example the Bosch BMP180 so might be worth investing the time to create a module.

Cheers

Ian

Hi Gordon,

A few metres below would be way too close to the rotor wash downdraft. In still conditions rotor wash extends to around 5m below (it produces 7kg of thrust). But for things like sensitive magnetometers it'll be necessary, so a long multi stayed drop line is more than possible.

For gas measurements, above the craft on a tall boom will work fine (induction side is much calmer) I'm especially interested in this as they are about to build a waste incinerator not 5 miles away. "They" say the exhaust gases will be safe but what you suggest is exactly what I want to do. I.e. Fly a 3D grid box downwind of the exhaust stack and monitor various gas levels. I already have the permissions of the farmers that own the land around the site because they are all concerned.

Flying the instruments opens up all sorts of possibilities. And glad to say I found the Espruino, makes it all so easy to throw on some sensors. :)

Cheers

Ian

@Gordon Magnetometer might be interesting to try, problem would be having it accurate enough to be useful but shielding it from the mass of mag fields from the brushless motors and power system.

I am looking at flying a dust sensor and various gas sensors on low air quality days to try and find the depths of those conditions.

Cheers

Ian

@DrAzzy No, no comms on it, yet. Plan is keep it independent of the airframe systems, so attaching it to the 433Mhz telemetry link is a no no. But there is no reason I couldn't add some form of downlink and ground station.

@Gordon Some graphs below but these are from the flight in the video above while, a) running on an Arduino Pro Trinket and b) using the temperature reading from the pressure sensor hence being a very laggy die temperature. That was the push to add a Max31855 and tiny K type thermocouple and add GPS for accurate time and position. All that led me to make the switch to Espruino. The whole thing has been running all day on the ground and giving sensible readings so is ready to fly. More once I've got some flights in.

Cheers

Ian

An extreme weather video (45knts gust while topping out): http://youtu.be/4TldITTHqmE

Hi All,

My little Espruino project is to build a sensor pack to measure the lower boundary layer of the atmosphere (up to 1000ft AGL) with a multicopter.

Weather balloons, or "sondes" as we call them measure pressure, air temperature and humidity, and via GPS drift calcs, wind speed and direction up to around 70hPa (way high). These are great and is awesome info. to feed into weather numerical models to forecast the weather for the next five days or so. Downside? They are complex to do and cost around £200 per flight, unrecoverable and use our dwindling helium reserves.

What if you are small civil or military airfield who simply wants to know if fog tonight is likely, or expected low cloud clearance time? Yes, you could throw a sonde in the air (if you have the gear). Or a glider school needing an atmospheric profile to judge soaring possibility? Vertical atmosphere profile for 1000ft or so, equally valuable.

So I've taken a COTS hexacopter kit that is now flying. I've also built a "sonde" using pressure (BMP085), air temperature (MAX31855 ADC + K thermocouple) and relative humidity (Honeywell HIH-4030) sensors. Time and position of data is important so I've added a GPS sensor.

Once a second, all sensors are logged to a flight file on the SDcard for later download (Vaisala commercial sondes log every two seconds). The platform flies a vertical profile from ground to max height at a specific rate of climb. Once landed, the data can be downloaded, analysed and used for those questions about fog, low cloud, thermals etc.

The multicopter logs it's own flight data and from that I've found you can get fairly accurate wind direction and sensible wind speed from the IMU data. This needs trials.

This was a fun project for myself, being a weather geek, but my employer is so excited about it, it'll be in flight trials in July.

I would just like to thank everyone who has helped, especially Gordon.

Ok, confirmed. It was the lack of unmounting the SD card that was causing the problems and multiple files.

So I've taken Gordon's example code above and modified to allow use of fs.appendFileSync (as I don't want to worry if a file exists already or not) and now it works really.

As long as logging is stopped before ejecting the SD card, doesn't matter if you create five logs or one, you can take the card out and put it back in again and everything is as you would hope.

This now makes a great basis for my little sensor logging project. I'll add the deep sleep back in once testing is finished but running on a battery it does indeed work well and doesn't affect the logging (I've yet to test it with the sensors though).

So, thanks again Gordon.

Cheers

Ian

var fs = require('fs');
var logFile;

function onInit () {
  
  var logInterval;

  setWatch(function() {
    
    if (logFile === undefined) {
      
     logFile = Math.round(getTime()) + ".txt";
     digitalWrite(LED2, 1); // indicator
     logInterval = setInterval(doLog, 1000);
      
    } else {
      
      clearInterval(logInterval);
      logFile = undefined;
      E.unmountSD(); // card can now be pulled out
      digitalWrite(LED2, 0); // indicator
      
    }
  }, BTN, { repeat:true, debounce:50, edge:'rising' });
  
}

function doLog() {

  digitalPulse(LED3, 1, 100); // pulse blue led as indicator
  fs.appendFileSync(logFile, getTime() + "\r\n");
  
}