Sorry, yup, you’re right. Wasn’t reading carefully. Limit would then be the size of the buffer in the CC3000 Host Driver minus the headers the host driver adds for the data on the SPI line.
Also, in order to support UDP packets not being sent until
endPacket() is called, we would need a new UDP send buffer.
I’ve avoided the packet size limitation by using one UDP request to collect the data and send the first half, then a second request that sends the second half of the data. However unfortunately even with @peekay123 's trick of reducing the receive buffer size I can’t stretch to 512 samples. I don’t get a red flash but I get flashing cyan and green - presumably something important has been overwritten. The RAM improvements are eagerly awaited! In the meantime the data are building up and looking interesting.
Morning @phec, just wondering how the data is going at your end over the last couple of weeks. Bees chewed through anything yet? Do you have any good graphs for activity yet? Yours, Richard
@richardfreeman, thank you for your interest. I have a growing collection of audio samples that seem to contain some useful information.
This picture is a set of 24 hourly sonograms running from midnight to midnight (16 samples collected over a second once an hour) - I’ve not mastered pylab yet so it isn’t labelled. The vertical axis is frequency, showing the first 45 bins of an FFT of the data at 22Hz per bin (EDIT - correction - I think it is more like 7.8Hz per bin) so hopefully the band at bin 13ish represents the bees’ wing beat frequency. The very marked peak around sample 150 is a tractor mowing the next door field and the peaks around sample 300 are a neighbour’s pressure washer. That is rural living for you.
The temperature profile has continued to show the steady cluster centre temperature while the outer reaches of the colony follow ambient temperature. I can also see the cluster growing and the temperature drop slightly when the young brood moves away from a region.The thermistors are now exposed but don’t seem to be suffering any problems.
I’ve got nothing sensible out of the optical signal yet - once I’d thought to switch off the Spark’s LED which gave me a very nice FFT pattern. I think I am sampling too fast and the sensor is too far from the entrance. I see the odd bee crawl over the sensor but don’t pick up the hoped for small variation in light level as bees enter and leave the hive. The optical signal changes a lot during the day as you’d expect but the short term variation is just in the least significant bit or two.
I’m working on the Mk 2 version which won’t be fastened to a brood frame but will be free standing. I’ve sunk a scaffolding pole in the ground near the hives so the antenna and PV are higher. I’ve also got a couple of neat DC to DC converters that will boost the PV voltage when the sky is overcast and keep trickle charging the batteries. Having two colonies monitored will help enormously with interpreting the data. (Edited: DC to DC converter gave me an extra 1/2 hr of power at each end of the day but reduced power by 50% for the rest of the time so I’m abandoning that route.)
I’ve ordered a Chinese copy of and Arduino GPRS shield so I can communicate with more distant hives and I’ve got some more microphones so I will be able to subtract a reference background noise from the bee signal.
I’ve looked into detecting the new queen piping to predict swarming. I’d need to keep the Spark listening most of the time which I don’t have power for (and the Spark doesn’t have enough RAM for). Also, by the time the queen and her daughters are communicating it is too late to stop a swarm. I hope that once I have cleaned up the audio signal I may get a rather less specific general overcrowding noise which may give me a bit of a clue. Failing that, a MOSFET artificial nose should do a good job of detecting the Queen Mandibular Pheromone level at the edge of the cluster because it has some chemically pretty simple components. These were all the rage 10-15 years ago but I’ve not seen anything for sale at a price I’m prepared to pay.
Thanks for the amazing detail here @phec - your knowledge of audio is far above mine, great to be able to track the sort of things we get near our hives too though, such as farm machines. It’s a shame the battery power to take a photo every now and again remotely is too high really otherwise that would be a good combination. I had never thought of trying to check for queen substance or not, but that’s a great idea. For me, it’s still going to be checking hive health, trying to predict swarming and recording the environmental conditions to see if they influence the first two parts which is probably my priority! Have your hives been packed up yet for the year? Hope all goes well anyway. Thanks, Richard
Someone asked what microphone I use and how is it connected to the Spark.
I use this microphone
I bought mine in the UK from Cool Components.
GND and VCC are connected to the GND and 3v3* pins of the Spark and AUD is connected to one of the Analog in pins. The breakout board provides a reasonable signal centred on 1.65v (ie mid range of the ADC) for speech at arms length or for nearby bees. Here is a typical sample of the raw signal transmitted by the Spark to my Raspberry Pi:
The Spark sends ADC values in the range 0 - 4095 and all I have done is subtract 2048 to get approximately centre zero.
Good to see more about the microphone @phec - are you packed up for the season now? Any plans to amend the kit for next year? Yours, Richard
Hi @richardfreeman, thank you for your interest. No we’re not closed for the winter - the bees are still bringing in some Himmilayan Balsam pollen and the queen is still laying. However you can see from the temperature profile across the cluster that the area with brood (above about 32.5C) has contracted quite a bit since mid July.
I’m going to keep monitoring through the winter to see how the cluster shrinks and see when they start to grow in the spring.
At some stage I’m going to swap the optical sensor for a second microphone so I can subtract background noises. When I have enough data I’ll do some pattern analysis - K means or Kohonen mapping to start with for data “compression” and clustering for classification. I’ve been thinking about putting the classifier onto the Spark so I can send the temperature profile and audio classification straight to an Android phone but at the moment the FFT is a bottleneck.
The GPRS variant is on hold until I’ve seen how I get on with the (not bee related) noise cancellation project - I’m getting more of the bits I need for this today having cooked an ST2012 audio amp last week.
I just wanted to chime in here with data length that you can store the data in 12 bit values (a 12 bit array). Normally you would be able to do this with bit fields, but you can’t do that with the spark compiler (issue filed).
I will be writing a library fairly soon to make this simpler for people, as it is something I would like to do.
On a separate note: @phec – can you post your working UDP code and python code in a gist? I would like to make a few libraries for doing UDP on the spark. If the code at the beginning of this topic is your final iteration, could you let me know?
Edit: I’m looking for a simple way to push data to a server through UDP – and this looks like the right place to look!
I’ve put the latest version with the primitive watchdog into a Gist. There is the spark cpp file, the python file that runs on a Raspberry Pi to control the Spark and a very short python script to plot out the daily audio measurements.
@CloudformDesign, if you are pulling together what you can find on UDP you may be interested in:
which seems more reliable probably because it has a more robust WjFi link. I expect that the code uses functions that have been renamed in the latest version of the core software but I haven’t had to recompile so they are still the old version. To squeeze the data into the available space I converted the ADC data to 8 bits.
Open Energy Management System
Having slowed the optical sample rate down to 666Hz I’m getting something that looks a bit more sensible out of the optical data:
This shows the variation in light level in the hive (the light source is daylight coming through the entrance) as a spectrogram. The flat periods are nighttime. The increases in higher frequency content are presumably greater bee activity and are accompanied by a lower DC light level since the entrance is partly obscured.
Someone has pointed out this Hackaday project which does something similar.
Great Work what you’ve done! I used some of your information to get the Fast Fourier transformation working on the spark core. It’s able to calculate about 400 samples. I’m wondering why you can’t get beyond 490 samples with your code only capturing and sending the samples. Maybe worth looking into the kiss_fft data structure for the fft_input.
More about that on opensourcebeehives.net
Any news on the kit there @phec and how it faired over the winter? Hope all is well. Yours, Richard
@richardfreeman, I’m afraid the Spark didn’t survive the winter. I couldn’t open the hive to check the hardware until a couple of weeks ago. It turns out that the Spark itself and the software are running fine but the WiFi range has dropped substantially to the level where I can’t communicate with the Spark when it is more than a few meters away from the house and nowhere near the beehives. It is the WiFi module/Spark rather than the antenna that is causing the problem.
At about the time I got this particular Spark - May 2014 I see that there was quite a bit of activity on this forum with people having trouble with cores that seemed dead on arrival and I think the eventual fix was to dry the cores out. I suspect that over winter the humidity got the better of the WiFi module.
I’ve ordered an Electron with all the solar goodies, so the bee monitoring will probably be on hold until the Electron arrives in the autumn though I will also think about whether I can redesign the Spark layout so that I can swap Sparks without having to open up the beehive.
@phec, you may need to consider a heated enclosure for the Core/Electron to prevent moisture from building up. Or, perhaps potting the device to create a hermetic seal.
@peekay123, yes - good point. Heating is tricky to engineer with only a solar power supply. Hermetic sealing looks the route to pursue.
The bees keep the centre of the hive a steady 30C and the humidity between 50 and 60% but this area is inaccessible as a site for the electronics.
Looking at dewpoint tables for 60%RH at 30C gives me a dewpoint of 21C.
The Spark, located just below the cluster, was between 25C and 30C for the whole summer and into the autumn. However early in October when the ambient humidity was high the Spark temperature dropped to below 20C and a few days later I lost WiFi. I guess in hindsight failure was pretty much guaranteed.
When I first put the Spark in the beehive in the late spring the bee colony was very small. The Spark temperature dropped well below 20C every night until the colony grew bigger but the ambient humidity was low and the small cluster of bees was far enough from the Spark not to affect it as a source of moisture. In contrast by October the ambient humidity was high and the cluster of bees extended quite close to the Spark.
I think your hermetically sealed suggestion is my best avenue. I won’t have a problem sinking any heat from the Spark as it only operates intermittently. I’ve already found from the PV/battery box that sits outside the hive that I’ll need to pay careful attention to effective sealing of the the power, antenna and data leads. Maybe I’ll try the experiment with a relatively cheap Photon first.
@phec, great points all around. You are not the first who will be considering potting the P0/P1 so it will be interesting to read about your experience. Where I am located (Ottawa, Canada) the temperature and humidity range is insane and hermetic sealing or enclosure heating are the only options. The sealing of the other components is another challenge as you pointed out.
I was talking to a very active beekeeping society on Saturday. They are interested in digging further into this technology. Unfortunately I see that the pictures have disappeared from this post (they were large).
I will look out my originals and forward a dropbox or onedrive link by private message if requested.
Yes, I don’t think I have any here at the moment @phec - maybe you could grab these from Google’s cache instead? Was it a group affiliated to the BBKA? I have found many local groups reticent about getting involved. We have the first version of the www.beelab.org kit coming out soon I hope - watch this space!