Notices


Reply
Thread Tools
Posts: 1,522 | Thanked: 392 times | Joined on Jul 2010 @ São Paulo, Brazil
#1
I would like to have a program to communicate in morse code, that offered multiple ways to both "hear" and "speak" in morse code.


Among other things, the following should be present:


For "hearing" (input) morse code:

* Monitoring the microphone for any morse code like sounds (including with white noise).

* Monitoring the microphone for morse code patterns in an specific frequency range

* Monitoring a live feed of the rear (as well as the face) camera for any blinking anywhere that looked like morse code.

* Monitoring a live feed of the rear (as well as the face) camera for blinking in an specific area and/or of an specific color that matches morse code.

* Monitoring the accelerometers for vibration/buzzing patterns that match morse code.

* Monitoring things like the environment light sensor, the proximity sensor, keys and buttons, the touchscreen etc for morse code like patterns.


* Same as with the mic, but for the FM receiver.

* Plain text, both typed live and by loading a previously saved text file.



And for "speaking" (outputting) morse code:


* Flashing the flash LEDs .

* Flashing the red recording LED.

* Flashing the status LED, including controlling which color(s)

* Flashing the keyboard backlights.

* Flashing the screen itself (with controls for color and perhaps even flipping custom images instead of just controlling the backlight)

* White noise out of the speakers.

* Configurable frequency out of the speaker, preferably with configurable waveform as well.

* Custom sound(s), both looping for changing length and two diffeerent ones for dots and traces.

* Same as the sound stuff but for the FM transmitter.


* Using the rumbler/buzzer.


* Decoded plain text output, live to the screen, redirected to text2speech, and saved to disk.





Ideally all inputs should be routable to all outputs (more than one at the same time) live, and if desired multiple inputs and outputs should be possible to be run at the same time; and each input with it's own routing setting.







With this it should be possible both to use two N900 to talk in morse code with each other under a variety of conditions AND use the N900 to talk with (and hear from) morse code coming from many other devices and even some manual morse code sources/targets.

Last edited by TiagoTiago; 2010-11-15 at 01:01.
 

The Following 2 Users Say Thank You to TiagoTiago For This Useful Post:
mveplus's Avatar
Posts: 66 | Thanked: 77 times | Joined on Jul 2010 @ intheclouds
#2
Would be great to have such program on N900!
 
Posts: 1,522 | Thanked: 392 times | Joined on Jul 2010 @ São Paulo, Brazil
#3
I imagine it could be made with a layers and plugins system, there would be an input layer that can hold any plugins that deal with inputs, the input plugins would report on and off status; then there would be a morse code interpreter layer, that would have plugins for translating a stream of on and off periods into standard morse code (perhaps somthing like a text stream composed solely of 3 characters, space, period and dash/minus sign) ; and then an output layer, the plugins there would read the standard morse code stream and convert it in whatever output the plugin is meant to. There would be a GUI for defining, editing and toggling different routes, the route data would be composed of a piece of data specifying the input plugin , another chunk of data for the parameters of the input plugin if any, then a piece of data specifying the interpreter plugin, then its parameters if any, and finally, the output plugin and its parameters.


With this approach i imagine it would be really easy to work with and adapt and enhance the whole thing, and we could already have a working thing a long time before most of the different input, interpreters and output variations are ready. Also, i see no reason for not being possible to have dummy loopback output/input plugins if necessary .
 
Posts: 1,522 | Thanked: 392 times | Joined on Jul 2010 @ São Paulo, Brazil
#4
Hm, now i realized that the layers approach as described above would be a tad awkward to work with when tapping code yourself since the output wouldn't necessarilly be synchronized to the input...Ok, how about having the output plugins be expected to accept both morse encoded stream and a raw binary (ones and zeros for on and off) stream, leaving the interpreter plugins to decide which one to send?
 
Reply

Tags
morse, morse code


 
Forum Jump


All times are GMT. The time now is 13:46.