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.

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!!!

 

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.