Programming Cycle Sound

This weekend the bicycle became perfectly ready.
Some nice test drives through the city got me really proud about its construction.

Plus, on Friday at the London Hackspace, I made a nice aluminium rack to hold the arduino. It still needs finishing, but it looks promissing.

Also, I assembled half of the interacting elements to the bike (only one side as it is symmetric). However there were some isolation issues that made the system short and therefore Pure Data was getting lots of trash!
I already isolated everything but haven't assembled it back.

Now I am working on the Pure Data patch. Not only that, as I am making a Lemur skin to work with the patch wirelessly on an iPad. It will allow easy multi touch direct access to several parts of the patch to modify elements along the way, such as threshold values, notes and octaves.
The sounds are now coming from Logic Pro. An amazing feature with this is that it allows me to have different instruments assigned to each of the interacting elements of the bike.

Even though the servos are still uncertain, counting on their inclusion, the functionality of this should look something like this:

More developments - moving quickly

Today was a quite intense day for the Cycle Sound project.

Started off with testing the XBee connection. This had been done very softly before and needed deeper understanding and testing.

Four things needed checking: a) all the pins of the XBee shield are sending; b) the analog pins are sending analog signal; c) the remaining pins of the arduino, despite not connected to the XBee, also send signal; d) Pure Data is receiving all signal, parsed as desired.

There is, however, another point to be tested: multiple simultaneous signals being sent and received and respective correct parsing. For this multiple connections to the arduino are needed.

After checking these points I proceeded to designing all the separate PCBs and a shield for connecting them to the arduino. As it was done their production starter: laser printing in photo paper, cutting the prints, cutting the copper board, transferring the prints to the copper board, etching the board, removing the toner, drilling and finally populating the boards.

I made a couple of mistakes on the way. Nothing serious.

1st - I didn't invert the shield drawing for printing. The others weren't important to invert as they were symmetric. And they were all printed in one go. I only realised this when I was already peeling the photo paper after the transfer had been done. Therefore, I had to go back to Illustrator, invert the image, print, cut the print and a new board, make the transfer again and so on...

2nd - the two very small hall effect sensor PCBs for the brake levers take a ratiometric hall effect sensor each. I assumed that it was going to work in the same way as the switch. Clearly I was wrong. But, luckily enough, I didn't have to make new PCBs for this. The problem was that I didn't test the sensors before making the PCBs. Anyway the difference was that they proved stabler without the resistor. I actually didn't test with different resistors but assumed that they would only interfere. Therefore I simply didn't insert the resistor.

The shield was done with surprising accuracy. However, the pin connectors aren't yet in my posetion. As soon as I get them I'll populate the shield. With it done, I can connect all PCBs to the arduino and make a full range test of the XBees, taking it to the park and making its first walk outdoors.

Hopefully, the brake calipers will also arrive soon and the bicycle will be able to join the XBees for a test drive.

Cycle Sound development

In the last week, great developments have taken place.

1st - The Bicycle. Very few parts are now missing to complete its construction. I am pretty stubborn and the choice I made was to build it from scratch. Piece to piece... Of course, in the end it's a much more expensive bike than it could be, but it is the bike I chose to make. I just need a deraileur, pedals and a saddle. Brake calipers are ordered and should be here by the end of next week. This means that in a couple of weeks it will be ready to ride. I'll spend the weekend assembling the bottom braket and crank. Sunday, I'll get the deraileur and possibly pedals. This means that by monday it will be a moving bike... However, it wont brake yet...

2nd - Electronics. All parts for the bike rigging are either ordered or already in my posetion. Most of the PCBs are made and tested but there are some to be made still. Mostly, what needs to be done is the inter connection of all parts and its assembly to the arduino. Thumbs up!

3rd - Wireless. It was a long frustrating strive to find how to make the XBees work together. Not only that in a simple way, but very specifically: a) making it transmit all the signals desired; b) getting the signals straight into pure data. However, I'm still not too shure about it fully working, whitch still requires some testing. This will take place very soon. One of the question marks I still have wondering around my head is about the transmition of all analog signal.

4th - Pure Data. The patch is pretty simple so far. I'm using FM8 to make notes from the patch. The development of this will be done when the electronics are fully functional and stable. Some things will probably be worked in the meanwhile to test the electronics.

 

Getting stuff together

I think that I'm at the point where I can start doing more with the results I've got. A good reason is that I think that I can't get any further with both the electronics and the programming to sort out the fine issues that I still have. These issues, as far as I can say, are latency and the fact that despite all my ignorant efforts to damp the signal from the piezo transducer in order to get only one signal spike, I'm still getting more than one.

Putting this aside, I got some pushbuttons from a scrap board that I found in the London Hack Space. I desoldered then and am using these recycled buttons to prototype.

I

In the end, what I'm doing now is having the piezo and 2 buttons connected to the arduino being read by pure data outputting to FM8. Just to test! And it works!

So, being more specific, the buttons only have a 2.2kohm resistor between output and circuit ground. The piezo however, has a 5.1v Zener diode, two Schottky diodes (bat85), and an RC (1M.4n7).

In pure data I switch to input the pins where the buttons are connected and to analog the piezo input.

To start simple, you can straight away look at the values coming out when you tap the piezo or push the buttons.

In this case I have the patch in a more advanced state, so I'm using the buttons to change the notes given by the piezo.

Also, yesterday I made the polystyrene bases for the pads on the handlebar of the bike. However, I had forgotten that planned on bedding the pad cases to attenuate more of the bike's input to the e piezos. This means that I have a gap between the pads and the case and therefore will be forced to make the bedding anyway. It is a bit annoying from the point of view of testing, but in the end the results are going to be much better.

I'm mounting this on a breadboard, but the intention is to make a PCB when the testing stage ends. This will make it much more reliable, small and easy to fit on the bike as I can design the PCB however I want and feel appropriate for its function.

 

Cycle Sound dataflow diagram

This diagram represents the data flow from its input (the bicycle) to the output (the speakers).

 

Proceeding with Cycle Sound

Last Saturday I went to Canary Wharf (aka Death Star) to meet with Ricardo Amaro. For what I though would be an up-to-three-hours meeting to get some things sorted, it actually extended to be a 10h attempt to get things going.

There were mainly two problems going on:

1st - the communication between the XBees ('modems');

2nd - the trim/threshold of the pulses from the piezo component.

For as much as I care to think and hope is that the issue with the XBees is sorted. However, we weren't able to confirm as there are other aspects that need to ready for that to happen.

As for the programming, the problems seemed to extend further.

To start with, we kind of gave up on using the pduino testing patch for pure data to start one from scratch. Along with that the arduino software came as an extension. This means that both arduino coding and patching in pure data are new built. This opens more possibilities and control over the desired elements. But also, it takes more time to build. Specially if your understanding of both languages is limited!

To sum up there's was the need to start from zero but we ended up with some good progress.