(Filename: aht8d-ATtiny Morse Chall.htm)
You know you'd do it for fun, anyway!
I will set out a challenge to the ATtiny85 community. If you can create the application I'm hoping for, you're in line for cash!
Worried this is a scam? Wise! It could be. But read the following carefully, and you'll see that all you have to lose is a little time, time spent doing something some people would find fun.
Actually, having worked on this for two hours, it occurs to me that something similar running in an Arduino would be fun, too. By all means follow all that is below, but using an Arduino instead, and you are inline for a smaller cash prize. Shall we change the $40/ $60/ $20 to $20/ $30/ $10, say? Also, in the Arduino "class", you don't have to send any hardware, just a clear description of how to set my Arduino up to test your code. (Quality of user documentation will play a big role in who wins the Arduino class. There should be two separate documents for users: Just how to use one that's been set up. (This would probably be quite short) And one to say what to connect to the Arduino to provide what is needed. And the interval between first finished entry being announced, and the deadline for submitting further entries would be extended to two months. For the Arduino version, the winning entry would have to be able to recognize all of the codes in the table given at Wikipedia.
Here's my idea. By all means, write, suggest changes...
Don't hesitate to get in touch if that needs clarification or tweaking.
I frequently speak of wanting this done in an ATTiny85. And I might well stick to that. (Except, of course, in respect of the separate, smaller competition.) No doubt ATTinys come in variants. If a different one would suit you... more program memory, perhaps?... do get in touch. If it is programmed the same way, and doesn't cost a lot more, and I find I can order them easily, they could be brought within the rules of the competion.
Your job is to create a little program to go into an ATtiny85. Hardware: (Here's the diagram from the top of the page again.)...
A momentary switch ("push button"), and LED, and wires to go to an external display capable of turning a stream of TTL ASCII signals into a display of letters. (I will provide the display. If your program can make messages appear in the Arduino Serial Monitor, you can do this too. In fact JUST sending them to the Serial Monitor (at the right rate) may be enough... I can probably tap the line that the Serial Monitor watches, and get what I need from that. (Pester me to determine that.))
As a user presses the button, if he/ she does so in a way that constitutes proper Morse code, at the right speed, the letters the Morse stood for will appear on the screen. The LED will be lit whenever the button is pressed, just as an "is the switch working" test.
Pester me to define "the right speed". (All of these "pester me" things are, I hope you agree, details which do not stand in the way of getting started with the project.)
"Frills" allowed... and will be used in judging "best entry". For instance, one of the GPIO lines could have a toggle switch on it. Set one, way, the "MorseReaderATtiny" (the name for this... please use in code, file names, etc, etc) will "understand" Morse sent at one speed, set the other, it will only understand it the code is coming at a different speed. The switch should be set up to provide one speed which is suitable to a rank beginner, and one that works for someone with some.. but not much!... idea of what they are doing.
By the way.. fell free to incorporate any "copyright left" material you can gather from the web... but please do the decent thing, and credit the originators with comments in the sourcecode. This will in no way diminish your chance of winning a prize. It might even enhance it, if you Do It Well!
Another by the way: The standard of the coding, i.e. what a programmer sees looking at the sourcecode, will be part of what I used to determine prizewinner(s). My decision on that final, by the way. I'm paying the piper, so... as they say.
You may have wondered about the red and green in my diagram, and the wavy lines. I meant to indicate the bits you must send me... red... and the bits I will supply... green. The wavy lines are there to say that I don't have strong views on what lines you use for what. I am new to ATtiny85 work, I'm not sure what restrictions apply. For instance, I don't know which lines are used by the Arduino IDE's programming and Serial Monitor. (Someone please let me know? I would prefer that neither be used, at least for the core design requirements, and that the signal for my TTL Serial Display be on a second line, even if it is merely duplicating what's on the output pin the IDE's monitor uses. (If you are pretty sure that two lines, duplicating a signal, are a bad idea, please write, let me know.)
The device should work (displaying the output on the IDE's monitor) with JUST the circuit on the left present. (And Vcc and Ground, of course.) If you've added frills, like the speed adjust switch mentioned above, great, and I will test them... eventually. Your MorseReaderATtiny should work with JUST he assets I've just listed. If there's something like the speed adjust input, the system should default to the most friendly settings.
The MorseReaderATtiny should cope with all of the codes which consist of just three dots or dashes. I/e. it should be able to recognize an R (dot dash dot), but doesn't have to recognize a P (dot dash dash dot). It will count quite heavily against you, though if that is all it can manage. Full alphabet would be much better. Anything beyond that: not necessary, but will get you some "bonus" points.
I imagine you will create some variables or constants in your code with values for the following. I don't expect you need all of them, but please use these names if you make them "byte-type" data, or as follows but starting "i" if you prefer to use an integer type.
Work through the names with me from top to bottom, which won's always be "left-to-right, top-to-bottom. (Why isn't there a word for that, and let's, please, not go down a "LTRTTB" path here! Pity something as grand as "boustrophedic" (a similar concept) hasn't been invented!)
If you work top to bottom (only, forgetting left to right), you'll get the terms in the order of how big the numbers will be, I think.
You don't have to work with these parameters in your code. But if you do, please refer to them thus.
bDitMin would be the smallest value. It would be the minimum time the signal has to be high to be seen as ANYTHING. Anything shorter than bDidMin is just ignored. (In this section, where ever I say things like "shorter than", feel free to add an "or equal to".) (I haven't put it on the diagram because I don't think the program needs it, but if you want to put a bOffMin in the program, to say, "if signal low between highs for less than bOffMin, ignore the brief off", then please use that name.
bDitMax (which MAY be the same as bDashMin) is the longest time that should count as a dit.
bDashMin, bDashMax similarly define dashes.
bBetweenLettersMin,-Max is for saying how long the line has to be low for the program to treat the "off" time as the break between two letters. In a moment I will use . for dot, _ for dash. Does the following...
Mean ANN or EMR? It depends on some slightly longer pauses the sender will put in, as follows... "/" means longer pause. (If I've got my example right!...
._ / _. / _. = ANN . / _ _ / ._. = EMR
(In The Mysterious Benedict Society, that issue is used very cleverly. (A sender isn't doing it very well, making it hard to spot the inter-letter breaks.) (It only took me ten minutes to recall the title! Even Google needed help, but eventually "childrens' book abducted orphans take over world island Morse code" did the trick!)
bBetweenWordsMin works the same way. A longer than "bBetweenLettersMax "zero" (signal low) means that not only have we come to the end of a letter, but also to the end of a word. Itissomucheasiertoreadthingswithbreaksbetweenthewords. (But try typing something like that? Your "do a space" reflex will be strong, I think you'll find.
If a "zero" goes on for a very long time, no problem! The program just sits in a loop, watching, so the display sits as it was left when the last letter was decoded. Simples.
Another bonus points opportunity: I suspect it would be quite easy to incorporate a "scaling factor", a way to make a change in just one place (even if it had to be done at the time the software compiled, uploaded to the ATtiny85), and have all (that you are using) of the various numbers indicated above get bigger or smaller, while retaining their original ratios.
That's it, I hope!
If you visit 1&1's site from here, it helps me. They host my website, and I wouldn't put this link up for them if I wasn't happy with their service.
Click here to visit editor's Sheepdog Software (tm) freeware, shareware pages.
Click here to visit the homepage of my biggest site.
Click here to visit the homepage of Sheepdogsoftware.co.uk. Apologies if the "?FrmAht" I added to that link causes your browser problems. Please let me know, if so?
Click here to visit editor's pages about using computers in Sensing and Control, e.g. weather logging.
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
....... P a g e . . . E n d s .....