Saturday, September 18, 2010

Hive Two - Second Inspection and some plans

Hive two now consists of 2 full depth, one .75 and a queen excluder. Its too big for my small yard now and I now have two young boys running around in the garden so the chances of bees getting squashed by them is increasing. They don't like being stung either...

I still want to try my hand at breeding a quantity of queens but I plan to use the top bar hive for that. The top bar hive still isn't populated. I did have it populated but they died out over winter. More on this in a later post...

There is a community garden just a few blocks away from where I live. They sound keen to have a hive there so I plan to move hive two onto their land. Because it is so close normally I'd have to move the bees twice. Once to a temporary location more than 5km away and then move them to their final location a few weeks later. This is because the bees are extremely good at navigating but forget to check where home is when they leave so if I move the hive a short distance the bees will take off in the morning, recognise the area they are in and so return to the old site.

To overcome this I plan to do the following
  1. Breed a new queen in hive two
  2. When the queen is almost ready to hatch move the current queen and some workers into the Top Bar Hive. If I do a graft today they should be almost capped next weekend (7.5 days) so next Sunday might be the time to make the move. Taking that into account, I won't do the graft today.
  3. At the same time move Hive two aside and place the Top Bar Hive in its place
  4. Move Hive two to its new location, about 1km away.
This should mean that any of Hive two's field bees that return to the old location will find their way into the Top Bar Hive, boosting its population. Any new field bees, heading out on their first flight, will orientate themselves based on the new location and return there.

In preparation for this I have located Hive two's queen and isolated her to the bottom box. I've also placed my queen rearing frame into the hive so that the bees can prepare it for a graft.

The hive is brimming with bees, every frame was reasonably well covered in bees, right out to the side walls. I weighed the top box (the .75) as I thought it would be interesting to see how quickly its weight increases. It is currently 16kg. This includes all the bees in the box at the time, 9 frames, a couple of frames of almost capped nectar and the remainder brood.

I've yet to see any significant varroa activity this season. I inserted a drone frame during the last inpection and it is almost all drawn out now. There was some brood in it but its not capped yet. Drone take about 14 days from capping to emerge so I want to remove the frame some time in the next two weeks. I spotted one worker with a mite on its back but otherwise all seems good. I still have put a sticky board in the mesh to see what the mite drop is, I really should get on to that.

Thursday, September 2, 2010

Solar Panel - Prototype One

After removing all the unusable bits of cell from the package I ended up with 99 cells that were at least full width or full height. I'm amazed at how fragile the cells are so its not really surprising that a few didn't survive the trip.

I found that securing any cracked cells to the glass with tape helped to avoid any further damage but get it right. There is no chance of removing the tape without destroying the cell. I'm not sure whats going to happen when the tape has been in the hot sun for a summer but hopefully everything is so tightly sandwiched that it won't matter.

The back view
I also found that soldering the panels while they were in contact with the glass was a stupid idea. The glass conducts the heat away far too fast to be able to get a good joint.

A bit of forward planning would have gone a miss. I ended up having to run a wire down the middle of the panel because I oriented both strips of panels the same. This meant the positive ended up at the top. No good when I want to connect them in series.

The front view
The silicon sandwiched between two sheets of glass takes a long time to set. Seal it and put it away for a week before playing with it. I used a bathroom silicon that reacts with water so hopefully the remain air trapped between the glass will be fairly dry.

Best result so far was 1.2Amps at 5.2 volts = 6.24w. Which is reasonably pleasing considering the state of the panels and the terrible soldering job and having to run the connecting wire down the center of the panel.

The panel cost about $6 for the cells and a couple of dollars for silicon and connectors. Call it $10 which makes it ~$1.60/watt. A lot cheaper then buying them but no 25 year output warranty.

Getting moisture inside the panel will be the biggest issue. We'll see how they go when I mount them outside. A local company Terranova operates a waste exchange. One of their clients is advertising factory second double glazing for free. I'm thinking I might be able to pop the end off and slide the cells inside. This would probably keep them dryer and be a cheap source of glass.

I metered a couple of power points around the house for a few months and found the following;

Fridge uses 0.72KWh/day
Internet connection, wireless router and switch use 0.24KWh/day

My first goal is to get the internet gear running off the panels. Assuming I get 6 hours of sunlight a day (very optimistic) I'd need a 40W solar array so maybe if I have a 100W solar array I might be able to do it. So far I've observed that 12 cells is required for 6W so I'd need 200 cells to archive this goal. Sounds like a lot but its how many I ordered so all I need now is more glass and lots more patience.

Windows to PIC Interface - (Hexapod Part 7)

The full source code can be found here.

In my last post I mentioned that the PIC randomly stops responding to instructions from the PC, although it holds the servo in position so the interrupt was still running.

My serial port monitor showed me that I was still sending data so it probably wasn't a problem at the PC end. I'm using a Prolific USB to serial converter so that could have been failing but it seemed unlikely. The key indicator that it was my firmware was that if I hard reset the PIC everything started working again.

After a quick debugging session with MPLab I found that it was stalled waiting for more bytes to arrive in the RX buffer. The offending code looks like this

SetPositions:
    btfss PIR1, 5 ;has something been received?
    goto $-2
    movf RCREG, w
;check for servo number
    btfss PIR1, 5 ;has something been received?
    goto $-2
    movf RCREG, w
    movwf SERVO0POS
goto CommsLoop

The problem is that when a comms error occurs, in this case a buffer overrun, the receiver is disabled. This meant the processor endlessly waited for bit 5 of PIR1 to be set, which indicates when something is received. I knew this routine was too basic when I wrote it but I didn't think it was going to bite me this early on.

The solution, which is not a complete solution, is to check for comms errors and if there is one, clear the error and resume receiving. This does mean that some data is lost and this can be observed. When the scroll bar on the UI is moved continuously (causing an overrun, I assume while the processor is in the ISR) a byte may be dropped. This will cause the servo to jump to the position of whatever byte is received when reception is resumed.

I think the proper solution is to use a second, higher priority, ISR that adds bytes received into a file register buffer for later processing. This may cause some latency in the servo ISR but should be small enough to have no noticeable impact. I'll also consider running the processor at 20Mhz, instead of 4Mhz. This would mean that receiving a byte and moving it into a buffer will have 1/5th the impact it would currently have.

Anyway, the current 'solution' (stop gap?) is as follows

SetPositions:
 call ReceiveIntoW ;wait for servo number
 ;check for servo number
 call ReceiveIntoW ;wait for position
 movwf SERVO0POS
goto CommsLoop


ReceiveIntoW:
 btfsc PIR1, 5  ;has something been rx'd?
goto CompleteReceive            ;yes, go deal with it
 btfss RCSTA, OERR ;has there been an overrun error?
goto ReceiveIntoW               ;no, go check for rx'd data
 bcf  RCSTA, CREN ;clear the error by reseting the receiver
 bsf  RCSTA, CREN
goto ReceiveIntoW               ;go wait again

CompleteReceive:
 movf RCREG, w
 return