OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | #planetgemini chat on matrix.org | #gemini-pda chat on Freenode | #zaurus and #alarmz chat on Freenode | ELSI (coming soon) | Ibiblio


Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
> Morse Code Input, Ultimately want morse code to speech
post Apr 30 2007, 08:26 PM
Post #31

Group: Members
Posts: 36
Joined: 29-March 05
Member No.: 6,732

QUOTE(Armagon @ Apr 30 2007, 08:48 PM)
QUOTE(jfr @ Apr 28 2007, 02:42 PM)
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.

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.]


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.
Go to the top of the page
+Quote Post
post Apr 30 2007, 11:03 PM
Post #32

Group: Members
Posts: 1,572
Joined: 7-April 05
From: Sydney, Australia
Member No.: 6,806

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 smile.gif 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
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:


RSS Lo-Fi Version Time is now: 19th April 2018 - 11:13 PM