Author Topic: Morse Code Input  (Read 9820 times)

jfr

  • Newbie
  • *
  • Posts: 36
    • View Profile
Morse Code Input
« Reply #30 on: May 01, 2007, 12:26:22 am »
Quote
Quote
To do the timing on the Z, you'd need to be confident that your userland program would be able to measure the timings of events with 10 to 20mS accuracy - preferably 10mS or better. I lacked that confidence, but I'd be very interested if anyone could prove me wrong.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160035\"][{POST_SNAPBACK}][/a][/div]

10 mS is a long, long time to the computer.  I make video games for a living, and we try to get 60 frames per second.  Every 16.7 mS, the games I work on need to do physics calculations, transform and draw thousands of polygons, process artificial intelligence, and so on.  Granted, the hardware we develop for is designed for this sort of thing, but you can do a whole heck of a lot in twenty milliseconds of computational time.

I would be really surprized if multitasking on the Z would skew your timings too much.  I expect you could use a standard message pump and take for the time stamp the time that you get the callback to process the event, and that the amount of time that this would be off -- probably on the order of microseconds -- would be far less than the amount of variation time your program has to account for when looking at human-provided input.  

[Hmm... It appears that a single task may get up to ten milliseconds in one go, on the high end.  That computing quantum is higher than I thought, and may actually cause you a problem.  I don't know what the actual time is for the Z.  It may be, though, that multiple timings are skewed by the same amount, and, especially since your task will be the only one running, I don't think it'll be an issue.]

Armagon
[div align=\"right\"][a href=\"index.php?act=findpost&pid=160140\"][{POST_SNAPBACK}][/a][/div]


I think you're very likely to be right - and for the archive, I agree with your point.

I note your "Hmm" though. I was trying to avoid getting involved with issues I couldn't measure, which is why I didn't want to go down that road. I don't have a problem with the amount the machine can do in a stated period of time, but I did worry about how long my program could potentially be backgrounded,

In my particular case:

Given that I'm developing this for one single individual, and given his particular situation, I'm not in the position where I can carry out experiments. Either it works first time when he's presented with it, or it's dead in the water. I feel more confident that my (let's say, in general terms unnessarily elaborate) solution will work out of the box, because I don't know how long the Z could take control away from my program, and I think I've evolved a solution where it isn't necessary to know that.

There's still the other issue: debouncing. A typical Morse key has brass contacts, and when contact is made, there's a whole lot of noise there. In my experiments, I found that the noise would persist for about two thirds of the length of a 20wpm dot. In my solution, the PIC does the debouncing, which makes the Z program a lot simpler. If the debouncing had to be done on the Z, I think the timing requirements would be an order of magnitude more severe. Well, either that, or I'd have to be a cleverer programmer than I am. Which is not likely to happen any time soon :-(

We've already seen in this thread the solution that I entirely missed: the use of the audio port, which by definition capures samples at regular and known intervals, and buffers them until you're ready for them. If I were starting again on this project, I think I might well begin there. That does seem to be a way of getting the Z to do the timings with accuracy.

Da_Blitz

  • Hero Member
  • *****
  • Posts: 1579
    • View Profile
    • http://www.pocketnix.org
Morse Code Input
« Reply #31 on: May 01, 2007, 03:03:34 am »
one thing that can help with debouncing is ethier some circutry which i am no doubt aware of (just a cap and resistor) or mechanical debouncing

jet a thin bit fo rubber and put thatin a postion so that the reber gets struck before the copper, this should slow it down enough that you dont bounce the contact.

i guess it all depends on your clicker  but i hope that trick helps

I love the audio port, its so versitile yet so over looked. sure it cant do high speed sampaling but for home stuff its fine. My electrical egineering course had one C class in it where they maintain a 486 with a bourland C compiler, the idea is that we can use them for playing with the low level hardware. its alot easier to play around when your  project and IDE are the same thing (they were running DOS)

had a nice little ossciliscope going that could also inject signals if needed
Personal Blog
Code
Twitter

Gemini Order: #95 (roughly)
Current Device: Samsung Chromebook Gen 3
Current Arm Devices Count: ~30
Looking to acquire: Cavium Thunder X2 Hardware