Reply
Thread Tools
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#51
Yeah, feel free to read through that thread that i linked with the post about the device node. The dbus implementation of it is pretty bad and requires some hacks to work at all. Far easier and more efficient to read the device node.
__________________

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
 
Benson's Avatar
Posts: 4,930 | Thanked: 2,272 times | Joined on Oct 2007
#52
Yeah, but if you can only poll at 15 Hz, I'd be fairly certain you're gonna get a lot of missed pulses.

I have to wonder if using the mic channel isn't going to be the only reliable way.



On the hardware side -- if you're hooking a phone jack to the N900, and need some sort of battery anyway for the sensor, it seems a shame just to pipe it back to earphones. Kick the battery capacity up a bit (7.4V, 10Ah or so), add a charger for the N900 (now we don't worry as much about excess drain of monitoring mic channel), some powered speakers, and wire my (~30W of LED) headlights in... I do like where this is going.

I'll just need to resurrect my old N810-era plan of sticking a USB webcam under the saddle for rearview mirror (now that we have OTG support coming soon), and we're good to go...
 
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#53
Benson, battery is not needed. Only dry reed and two resistors. Link to description and photos are in my previous post.
 
Benson's Avatar
Posts: 4,930 | Thanked: 2,272 times | Joined on Oct 2007
#54
Originally Posted by KiberGus View Post
Benson, battery is not needed. Only dry reed and two resistors. Link to description and photos are in my previous post.
Ah, gotcha. I still wanna build the whole thing.
 
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#55
So, there's some strange behavior. It seems the refresh rate of the device file increases as the button press-rate increases, but to what extent i don't know because i can only press the button so fast.

So, here's a very basic app to poll presses and report the frequency and approximate speed (based on 2m/revolutiion). Do you have a "real" bike computer to test its accuracy? If not then if you could check to see that it seems to scale up to higher than 5 Hz accurately, it may be worth putting more time into (i.e. GUI etc). I ended up stripping out everything besides a basic polling loop, so it's very simple right now.

Suggested means of basic testing (in absence of "real" bike computer): flip bike and spin wheel. Note speed reported. Increase speed of spin slightly and check that reported speed increases slightly. Repeat...

Oops, to run the app, type /opt/maemo/usr/bin/maebike.sh. I forgot to take out the trigger file so you have to run that script twice after you kill the app (ctrl-c) to run it again.
Attached Files
File Type: deb bike.deb (6.4 KB, 88 views)
__________________

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-12 at 13:21. Reason: Instructions
 

The Following 2 Users Say Thank You to Flandry For This Useful Post:
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#56
Flandry, unfortunately it misses most part of signals, especially on high speed. I think that only one of 50 is detected They are very very short. Can you please publish sources, so as I would be able to make more tests.
 
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#57
It's a mess of commented-out code right now but if it doesn't work, that's a dead end.

It takes an initial time, polls the device file in a tight loop 60 times, takes the end time, and then divides the detected presses by the difference in time and prints it. Then it does it all over again. If it's missing presses in a tight loop, i don't think we can do any better using that resource. Back to the audio approach?

I'll copy and paste the snippet of code that actually does the relevant stuff when i get home from the lab.

Edit: Looking through that, i think i accidentally uploaded a version that calls nanosleep, so it might not be optimal. Try the version attached to see if it's any better.



Code:
#include <sys/time.h>
/* Headset button (AKA sensor) device file */
static const char *button_filename = "/sys/devices/platform/nokia-av/detect";

int read_button()
{
  FILE *fd;
  char button = 0;

  fd = fopen(button_filename, "r");
  button = fgetc(fd); // 4 is open, 2 (or 0 for hacked wiring) is closed
  fclose(fd);
  if (button == '4') return 0;
  else if (button == '2' || button == '0') return 1;
  else return -1;
}

int do_poll(int samples)
{
    int presses = 0, button_status, old_button_status = 0; // WARNING: Assuming button is open at start could lead to overcounting presses by 1/frame
    for (int i=samples; i > 0; i--)
    {
      button_status = read_button();
      if (!old_button_status && button_status > 0)  presses++; // No error checking
      old_button_status = button_status;
    }
    return presses;

int main(int argc, char **argv)
{
  struct timeval start_poll, end_poll;
  float elapsed_time;
  while(1) { // Begin main loop. This only exits if a trigger file that was specified is deleted.
    gettimeofday( &start_poll, NULL );
    presses = do_poll( 60 );
    gettimeofday( &end_poll, NULL );
    elapsed_time = (float)(end_poll.tv_usec - start_poll.tv_usec)/1000000.0;
    elapsed_time += end_poll.tv_sec - start_poll.tv_sec;
    printf("Revolutions: %i Elapsed: %0.2fs Hertz: %0.2f Approx. speed: %0.1fm/s\n", presses, elapsed_time, (float)presses/elapsed_time, presses*2.0/elapsed_time);
  } // End main loop
  return 0;
}
Attached Files
File Type: deb maebike_0.0.1_armel.deb (6.4 KB, 79 views)
__________________

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-12 at 21:01. Reason: Snippet added
 
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#58
No it still misses pulses. So I'll try audio. It shouldn't be so much power consuming because it is many times simpler, than decoding audio when playing audio. So it should live longer, than audioplayer with switched on screen.
 
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#59
I've tried sound approach. It works well. Python implementation eats about 30% of CPU. I would like to rewrite it in C, python was chosen because I've found good example if reading sound via gstreamer.
Right now I'm going to test it on the street.
 

The Following User Says Thank You to KiberGus For This Useful Post:
Posts: 254 | Thanked: 122 times | Joined on Nov 2009
#60
The script itself and battery usage measurements.
http://kibergus.su/node/45
I hope, that C variant would consume less CPU.
 
Reply


 
Forum Jump


All times are GMT. The time now is 09:43.