Cycle Sound - assembling the electronics on the bike

So, the bike is ready. An excellent ride I should add.

The electronics are ready to assemble. But the bike is not ready to receive them. Simply because there is no place for buttons, sensors and drum pads on a bike!

Well, but I'm making place for it.

Here's some snap shots of what I've done so far. I must say as well that everything I've done is tested and it's working.

Linear hall effect sensor and magnet on the brake levers.

Hall effect sensor switch and magnet on crank wheel for cadence computation.

Mini rear rack to hold the arduino, xbee shield, xbee, cyclesound shield, antena and batteries.

 

Soon enough the weather will be suitable for proper park testing! Can't wait for the day to come.

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.

Bike one step away!

As I was saying, by today I should have the bike assembled except for the brakes, which are supposed to be delivered by the end of the week. This means that within a week the bike will be fully operational and I will have already tested it!

We are getting there!!!

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.

 

A little board

After testing the push buttons on the breadboard and making sure that everything was in order, I decided to make a small PCB with the whole circuit.
Designed it in Adobe Illustrator. The reason is that I don't really get anything from EAGLE and also couldn't find the buttons to make the layout!
So, with a bit of old school technique (a ruler) I made it work.
Here it is!

 

 

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.

 

Rework to python

Last Saturday I met again with Ricardo Amaro in very fruitfull afternoon towards the making of Cycle Sound.

We spent a lot of time installing libraries and modules and stuff... It pretty time consuming. Anyways, the point being trying to migrate part of the project to python. The language is easier and there is a greater array of possibilities with it than with the Arduino software. Mostly because with the Arduino software we can only work within the Arduino. With python we can work/communicate with Arduino along with being able to control other softwares and/or platforms.

So, towards the programming of Cycle Sound, we got hold of controlling parameters given by Arduino. We are still working our way around the piezoelectric as a sensor. I think we made quite a good progress, however it made me realise that the problems, or most of the problems we are having with the piezoelectric are not from the software domain but rather from the hardware. Electronics!

The information available online of how to go around piezoelectric issues when connecting it to an Arduino is very scarce and hard to find. However I found a great article on it which hopefully is going to get me through the main problem.

The problem is the signal peaks given by the piezoelectric. The point is to make the piezo a clean single "bang" signal containing a value that is to be transformed into midi velocity. There is nothing (or probably not much, very complex and not very effective) that software can do to go around this. So it comes down to a simple small circuit between the output of the piezo and the input of the Arduino. A couple of diodes and an RC are meant to do the job. I haven't fully tested this as I'm still waiting for one of the diodes to be delivered but I have quite high expectations, I must confess.

If the result proves effective, I will be confirming it over here. I will give the different possibilities that I tested and report the best results. I don't have an oscilloscope or anything to measure the signal in a controlled manner, but in the end, it's the results on the project that I'm interested in.

If it all works according to expectation, this is a great step towards any kind of drum machine with a great controll level and sensitivity.

Looking forward to the results!!!

 

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.