Reply
Thread Tools
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#41
Originally Posted by KiberGus View Post
I haven't done that, but i definitely know, that it is possible. People have successfully used sound cards as oscillograph. Microphone input can register variable current under 2 volts (if i'm not shure about parameters, maximum allowed voltage and current should be investigated).
You should place magint like this on a wheel http://www.chip-dip.ru/product0/9000033861.aspx
Put dry reed (http://www.chip-dip.ru/product0/59097.aspx) on a fork. I was mistaken about price, it costs about $1.5, there are similar pieces for $0.2, but looks like they are out of stock. Then you need a battery to get a power and a resistor, which would adjust voltage and current to needed limits. When magnet is near reed, reed closes circuit and DAC in the phone would be able to detect it. You would also need a 3.5 mm jack nest ($0.8) to connect headphones (if you wish) and 3.5 mm 4pin jack to connect to phone (it's hard to find one, so cut one off from garniture, nokia gave you with the phone).
If you would listen recorded audio you would hear a "click" sound. Such click can be easily detected by software.
This is one of those cases where i would say "Pics or it didn't happen." While i agree in theory it's possible, i'm far too lazy and pessimistic to go to all that trouble without demonstration of an operational prototype on the N900.

How would you design the software to minimize battery use? I expect sound processing is a bit cycle intensive (pun intended).
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful
 
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#42
Originally Posted by Flandry View Post
This is one of those cases where i would say "Pics or it didn't happen." While i agree in theory it's possible, i'm far too lazy and pessimistic to go to all that trouble without demonstration of an operational prototype on the N900.
I did some tests and from hardware side it works, i can clearly hear clicks, when dry reed closes. So now, when I know what elements in what order should be conected I need to assemble it properly, not by twisting wires on the table.
Originally Posted by Flandry View Post
How would you design the software to minimize battery use? I expect sound processing is a bit cycle intensive (pun intended).
Does music player consume much of battery? Sound analyzing would consume much less, because we only need 5 operations per measurement in worst case (we search for loud clicks). Reading data from microphone would require more. But I think, that we can set minimal sample rate available.

P.S. I usually don't cycle more than for two hours. And, anyway, its fun.
 
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#43
Well, I've finished soldering. Hardware works and "clicks" are recorded by maemo-recorder. More detailed description will be available soon.
 
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#44
Originally Posted by KiberGus View Post
Well, I've finished soldering. Hardware works and "clicks" are recorded by maemo-recorder. More detailed description will be available soon.
Hey, what about wiring it so that the reed switch is closing the circuit used for the headset button? No need to process audio at all!

Polling this device node shows the status: http://talk.maemo.org/showpost.php?p...5&postcount=64

If you want i can make some code to do it and show the frequency.

The only potential problem is see is device file not being updated at a high enough frequency to be accurate, but it's worth a try since it's easy and you've already got the hardware bit. We've lost the mic usage by your method so no additional lost functionality (i think).

The only thing a quick google about how the button is wired turned up is this:
http://webcache.googleusercontent.co...ient=firefox-a

Whether it's the same for the N900 headset i couldn't say, but i could check it out at work with a multimeter on Monday.

I might actually have to make one of these myself.
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful

Last edited by Flandry; 2010-06-06 at 12:49.
 

The Following User Says Thank You to Flandry For This Useful Post:
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#45
Originally Posted by Flandry View Post
Hey, what about wiring it so that the reed switch is closing the circuit used for the headset button? No need to process audio at all!

Polling this device node shows the status: http://talk.maemo.org/showpost.php?p...5&postcount=64

If you want i can make some code to do it and show the frequency.

The only potential problem is see is device file not being updated at a high enough frequency to be accurate, but it's worth a try since it's easy and you've already got the hardware bit. We've lost the mic usage by your method so no additional lost functionality (i think).

The only thing a quick google about how the button is wired turned up is this:
http://webcache.googleusercontent.co...ient=firefox-a

Whether it's the same for the N900 headset i couldn't say, but i could check it out at work with a multimeter on Monday.

I might actually have to make one of these myself.
It looks like button is implemented in the same way. It is connected in parallel with mic and shorts circuit through 47 Om resistor. I used 500 Om resistor at first, but it produced too loud clicks, so I switched to 2 kOm, which does not lead to overloading audio tract.
Through, it should be safe to short mic wires because this is how headphones are detected. When I disassembled mic module I already had working scheme, and I decided to stick to it. And I don't have 50 Om resistor near me.
So, button sensing could be as power consuming, as sound analysis.

Mic is connected to two contacts on the jack which are closer to wire. Outer one is ground, inner is mic. If they are shorted phone thinks, that headphones are connected, if there is resistance about 1 kOm (it should be less, than 1.5 kOm, I didn't search lower bound) phone thinks, that headset is connected.

P.S. If you don't want to loose your headset I can make photos of mine.
 
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#46
Flandry, thanks, with my schematic
cat /sys/devices/platform/nokia-av/detect
gives 4 when reed is not shorted and 0 if it is shorted. So it is possible to poll /sys/devices/platform/nokia-av/detect or, may be, if for this file urgent reed events are generated, we could even make this effective.
 

The Following User Says Thank You to KiberGus For This Useful Post:
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#47
Originally Posted by KiberGus View Post
Flandry, thanks, with my schematic
cat /sys/devices/platform/nokia-av/detect
gives 4 when reed is not shorted and 0 if it is shorted. So it is possible to poll /sys/devices/platform/nokia-av/detect or, may be, if for this file urgent reed events are generated, we could even make this effective.
I did a rough estimate that the maximum frequency that would have to be detected is 15 Hz*, which means about a 30 Hz sample rate. I have no way of pressing the button in a controlled way at 15 Hz to test this, but i can get about 5 Hz by hand detected with the current code. I need to change it to measure delta time because nanosleep is imprecise.

The trick here is going to be to balance poll frequency and update interval to avoid killing battery life. I still think there's no way audio analysis will be able to compete for battery usage, but the active polling could be a drain just because it doesn't allow the processor to enter sleep state

Edit: Have a project due this week so no more time on this for now, but i will try to get a functional app out next week to test it. If you could post a photo or two of your setup, i'd appreciate it. It seems like it would be best to wire up an adaptor with a lead running off for the switch.

* ~Smallest non-recumbent adult bike tire is probably 1" (2.54 cm) mountain bike (26") tire, which has a 1913 mm circumference (1). Using a very generous 100 km/hr = 27.8 m/s as top speed, the maximum frequency is 27.8/1.913 = 14.5 Hz.The lowest practical frequency is around 0.5 Hz (4 km/hr with 700 X 44 (2244 mm circumference) tire. It seems there may have to be a tradeoff on accuracy at one end or the other for practical reasons.
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful

Last edited by Flandry; 2010-06-06 at 17:16.
 
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#48
No time towrite normal text now, may be tomorrow. So just several photos with needed details, scheme and resulting construction. I didn't added headphones nest because appropriate part was absent in a shop.
http://kibergus.su/?q=gallery&g2_itemId=183
P.S. I don't have phone mount yet. Don't askabout it.

Flandry, should I bother with writing software or you already did it?
 
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#49
Originally Posted by KiberGus View Post
No time towrite normal text now, may be tomorrow. So just several photos with needed details, scheme and resulting construction. I didn't added headphones nest because appropriate part was absent in a shop.
http://kibergus.su/?q=gallery&g2_itemId=183
P.S. I don't have phone mount yet. Don't askabout it.

Flandry, should I bother with writing software or you already did it?
Yay, drupal.

As i mentioned, i've got a project due this week so it will be a few days before i can deliver a complete app to test it.

It appears that ~15 Hz is the best that the sensor device file can manage, so that might be a problem. There are still some things to try, though. 7 Hz wheel rotation is still about 50 km/hr, so still useful IMO. It remains to be seen if it will miss really short presses with a slow poll rate. Will update the thread when i have an app to test with.
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful
 
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#50
Here is a description, how to make a sensor.
http://kibergus.su/en/node/39
By the way, doesn't maemo emit dbus signals, when buttons on headset are pressed? We need to start
dbus-monitor --system
and check. Some events are generated, vhen headphones are inserted and uplugged. I can't make tests with the sensor or headset because they are about 50 km from me now.
 
Reply


 
Forum Jump


All times are GMT. The time now is 04:38.