SM-1000 UI thoughts

[Stuart Longland]

Hi all,

Just been doing some thinking with the SM-1000. There's talk of adding
the 700B mode to the devices, already there's the ability to switch
between analogue and digital.

Other features that'd be useful include VOX and time-out timer.

For a user interface, we have the following controllable from the MCU:

- Audio output
- Four LEDs (Power, PTT, Sync, Error)
- Three pushbuttons (Select, Back, Internal PTT)

Providing prompts to the user will be a challenge. Using voice
recordings is an option, however who wants to sit there recording voice
prompts all day, and how do we maintain consistency?

Morse code can be achieved easily enough in code. I did it some time
back for a MSP430 based console with similar limitations (just LEDs),
and was able to implement a crude morse code flasher for flashing up
numeric error codes. Letters would be useful in this context, not hard
to implement.

Probably a short beep when an option is selected, then play the
recording or morse message after a delay (maybe ~1sec) might be an option.

The user can then move between the options just counting beeps, but if
they lose count or forget where they were, they can just wait a moment
and they'll be told what option they're on.

Morse or voice, this is only half the problem though. The elephant in
the room is user input.

The PTT button has a dedicated purpose. We could use it as a shortcut
to exit the menu system and return to normal operation, but using it to
confirm a selection is probably unwise.

That leaves just two buttons, to perform the following actions:

- Confirm a selection
- Move to the next selection
- Move to the previous selection
- Cancel a selection

We could just reduce that to the first two, just have SELECT keep
cycling between the options, and we confirm it when they hit BACK, but
suppose the user changed an option by mistake? It's also cumbersome if
there are a lot of options. (Think time-out timer, in increments of 30
seconds up to 5 minutes.)

We can consider each button to have two possible actions, a short
momentary press, or a longer (>1 sec) press. So we could map the
actions as follows.

- short press SELECT: Move to next selection
- short press BACK: Move to previous selection
- long press SELECT: Confirm this selection, return to
parent menu (or exit menu)
- long press BACK: Return to parent menu (or exit menu)
without changing any settings
- PTT (long or short press): Exit menu without changing settings.

The power LED should probably blink quickly to indicate we're in a menu.

Entering a setting menu should put us on the current setting. PTT could
be flashed in morse code to indicate the currently chosen setting on a
loop. (Something that would get quickly irritating as audio, those
Quangshang radios are bad enough!)

A hypothetical menu structure could be as follows:

1: MODE:
1.1: ANA: Analogue mode
1.2: 1600: FreeDV 1600
1.3: 700B: FreeDV 700B
2: VOX: Voice activated Transmit
2.1: EN: VOX Enable?
2.1.1: N: No
2.1.2: Y: Yes
2.2: TRIG: Trigger threshold.
Trigger level adjusted from 16 possible thresholds.
2.3: HOLD: Hold threshold.
Trigger level adjusted from 16 possible thresholds.
2.4: DEL: Hold delay
Hold delay adjustable from 0 to 2000ms in steps of 100ms.
2.5: CAL: Calibrate threshold.
This could give a beep to signal you to say something,
beep again to stop, and measure the mean sound levels
to calibrate the trigger and hold thresholds.
2.6: TEST: Test the settings, PTT illuminates
while VOX is triggered, but no transmit
takes place.
3: TOT: Time-Out Timer
3.1: EN: Enable timer
3.1.1: N: No
3.1.2: Y: Yes
3.2: TIME: Time period in tenth-minutes.
Adjustable from 0.5 to 5.0 minutes in 30 second increments.
Given as tenths of a minute.
3.3: WARN: Time period before time-out for warning.
Adjustable from 0.5 to time-out period in 30 second increments.
Given as tenths of a minute.

So supposing that the user was trying to call using the 700B mode and
wanted to switch to analogue:

-> Hold down SELECT (1sec)
<- Beep is heard, power LED starts flashing. 'MODE' is heard after delay.
-> Hold down SELECT (1sec)
<- Beep is heard, '700B' is heard after delay.
-> Press SELECT
<- Beep is heard
-> Press SELECT again (before 1 second is up) then wait
<- Beep is heard, 'ANA' is heard after delay.
-> Hold down SELECT (1sec)
<- Beep is heard, 'MODE' is heard after delay.

Suppose they want to turn on VOX:
-> Hit SELECT
<- Beep is heard, 'VOX' heard after a delay
-> Hold SELECT (1 sec)
<- Beep is heard, 'EN' heard after delay
-> Hold SELECT (1 sec)
<- Beep is heard, 'N' heard after delay
-> Hit either SELECT or BACK
<- Beep is heard, 'Y' heard after delay

Supposing they realise they're not in a good location for that, they can
back out:

-> Hold BACK (1 sec)
<- Beep heard, 'EN' heard after delay.

So VOX is still off because the cancelled the selection.

Holding down the SELECT or BACK buttons, or pressing PTT will take them
out of the menu. Momentarily pressing SELECT or BACK will just move
between 'MODE', 'VOX', 'TOT'.

-> Hit PTT momentarily
<- Beep is heard, power LED ceases flashing.

The beep could change in pitch to hint where you are in the menu without
hearing the prompt.

I haven't written any code for the above, this is all just hypothetical.
I think before we cram too much into these things, we need to give some
thought as to how they'll be accessed and set.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[David Rowe]

Hi Stuart,

Thanks for your ideas. I am looking for someone who would like to work
on the C coding for the SM1000 UI. Please contact me if you are interested.

Voice prompts could be stored efficiently using Codec 2 compression. I
imagine we have some nice studio voices out there in Ham land that could
be used. The voice actor could read a script of the 20 or so words we
need, then some one would need to segment these into separate wave
files, compress, and use a utility to pack into C header files.

I'm OK with using PTT as an "OK" button when in "menu" mode. It's just
another GPIO, and can be disconnected from the radio PTT line in
software when in "menu" mode. So that's gives us a three buttons,
select, back, ok which should be enough.

Another possibility is a limited vocabulary voice recognition, using the
Codec 2 encoder routines to extract model parameters that we can match
to a set of templates. Imagine saying "Set squelch 2dB". If anyone
would like to work on this please contact me.

Still another way is a command line terminal interface using the USB
port, so a PC could be used. e.g. for setting a call sign. There is
already some virtual serial port code in codec2-dev/stm32.

IIRC it's possible for STM32F4 C code to write to the STM32F4 Flash to
store persistent configuration data, some one will need to come up with
a driver for that.

Cheers,

David

[Stuart Longland]

Hi David,

On 30/08/15 18:00, David Rowe wrote:
> Thanks for your ideas. I am looking for someone who would like to work
> on the C coding for the SM1000 UI. Please contact me if you are
> interested.

I can't promise a lot of time to be spent on this, but I can look into it.

> Voice prompts could be stored efficiently using Codec 2 compression. I
> imagine we have some nice studio voices out there in Ham land that could
> be used. The voice actor could read a script of the 20 or so words we
> need, then some one would need to segment these into separate wave
> files, compress, and use a utility to pack into C header files.

Indeed, the problem is getting someone who would be willing to "be the
voice", and how to handle later additions. You've either got to put up
with the voice suddenly changing or get the person back again.

Morse code packs in even tighter, so in the short term we can do the
Morse interface while we flesh out how the menu will be structured, then
later when things are more concrete, we can contract someone to record
the voice prompts.

Fundamentally, there's little difference from the menu interface
perspective, just calling a different function to generate the waveform.

> I'm OK with using PTT as an "OK" button when in "menu" mode. It's just
> another GPIO, and can be disconnected from the radio PTT line in
> software when in "menu" mode. So that's gives us a three buttons,
> select, back, ok which should be enough.

Yep, I did look into that, at first I thought it might've been in
parallel with the external PTT, or switched via the socket.

Reading the schematic informed me that they were separate, with the PTT
button doing double-duty as a boot mode selector switch.

I considered that as an OK button, my reasoning for deciding against it
was more along the lines of, what happens if you're in a menu, forget,
then go to transmit?

If I make it exit menu mode, it serves two purposes:
- The forgetful operator won't accidentally set some parameter they
didn't intend.
- An operator who gets lost in the menu structure or needs to get back
to some known point in a hurry can do so with minimum fuss.

e.g. switching modes, they can hold SELECT twice, tap SELECT or BACK any
number of times needed to select the desired mode, hold SELECT again,
then hit PTT and they're switched.

> Another possibility is a limited vocabulary voice recognition, using the
> Codec 2 encoder routines to extract model parameters that we can match
> to a set of templates. Imagine saying "Set squelch 2dB". If anyone
> would like to work on this please contact me.

I once had a Nokia 3310 mobile phone that had that, you could record
voice tags for up to 10 different numbers, and it would do pattern
recognition to figure out which one you wanted to call.

It was surprising how well it worked given the constraints of the CPU,
probably not dissimilar to what the SM-1000 uses. (I'll bet the 3310's
CPU didn't have IEEE754!)

Still, while it could work in a radio shack, out in the field I'm not so
sure. Then there's language processing: identifying individual words is
one thing, interpreting them quite another.

> Still another way is a command line terminal interface using the USB
> port, so a PC could be used. e.g. for setting a call sign. There is
> already some virtual serial port code in codec2-dev/stm32.
>
> IIRC it's possible for STM32F4 C code to write to the STM32F4 Flash to
> store persistent configuration data, some one will need to come up with
> a driver for that.

Yep, and it'll need the intelligence to know *when* to write, so as to
not unnecessarily burn out the flash.

One question I do have though. I note there is a STLink header, but no
JTAG, which I'm more accustomed to. (I don't have any STLink compatible
programmers on hand.)

I've read somewhere the procedure for loading firmware into the device
is via the USB port, powering up with the PTT button down. Question is,
if the firmware is faulty, how does one recover?

I'm concerned that a bad upload of firmware could wipe the bootloader
present on the device and brick it. If I had JTAG, no problem, I know
how to recover that, but with STLink, I'm not so sure.

[David Rowe]

Hi Stuart,

Re voice rec a limited vocab (20 words ish) will make it easier to be
accent independent. We have a close mic to work with so background
noise won't be a show stopper. As it's open source ..... the speech rec
can be hacked or tuned by anyone with a different language.

The USB bootloader is in ROM, so it's unbrickable. I think the STLINK
interface is hardware, so same deal.

Cheers,

David

[Stuart Longland]

[Stuart Longland]

On 30/08/15 15:29, Stuart Longland wrote:
> Just been doing some thinking with the SM-1000. There's talk of adding
> the 700B mode to the devices, already there's the ability to switch
> between analogue and digital.
>
> Other features that'd be useful include VOX and time-out timer.
>
> For a user interface, we have the following controllable from the MCU:
>
> - Audio output
> - Four LEDs (Power, PTT, Sync, Error)
> - Three pushbuttons (Select, Back, Internal PTT)
>
> Providing prompts to the user will be a challenge. Using voice
> recordings is an option, however who wants to sit there recording voice
> prompts all day, and how do we maintain consistency?
>
> Morse code can be achieved easily enough in code. I did it some time
> back for a MSP430 based console with similar limitations (just LEDs),
> and was able to implement a crude morse code flasher for flashing up
> numeric error codes. Letters would be useful in this context, not hard
> to implement.
>
> Probably a short beep when an option is selected, then play the
> recording or morse message after a delay (maybe ~1sec) might be an option.

A heads up for those who may not be following the freetel-codec2 list.
This is being actively worked on. There is an experimental binary, and
patches available at

http://stuartl.longlandclan.id.au/freedv/sm1000/2015-09-04/

which is a work in progress: presently all it does is announce what mode
you're in ("ANALOG", "DV" or "TONE" in Morse, 20 words a minute) as you
hit SELECT. Persistent storage of settings and the actual menu state
machine are all that's missing.

If people have ideas on the menu structure and UI thoughts, I welcome them.

Regards,

[Walter Holmes]

Stuart,

Is the sm1000.bin file here one that has the current patches applied already, or is that the original sm1000 binary?

If you have a patched binary at a point ready to be applied and tested please let me know as I would like to give it a try, so I can then convert it to a .dfu file so that Windows users can flash it into the sm1000 as well.

Many thanks for all the great work you guys are doing on this.

Walter/K5WH

--
You received this message because you are subscribed to the Google Groups "digitalvoice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.
To post to this group, send email to digita...@googlegroups.com.
Visit this group at http://groups.google.com/group/digitalvoice.
For more options, visit https://groups.google.com/d/optout.

[Stuart Longland]

Hi Walter,

On 19/09/15 16:24, Walter Holmes wrote:
> Is the sm1000.bin file here one that has the current patches applied
> already, or is that the original sm1000 binary?
>
> If you have a patched binary at a point ready to be applied and
> tested please let me know as I would like to give it a try, so I can
> then convert it to a .dfu file so that Windows users can flash it
> into the sm1000 as well.

That file is patched (no point in publishing the unpatched version,
David offers the exact version that shipped with the SM1000).

[Tony Langdon]

On 19/09/2015 1:44 PM, Stuart Longland wrote:

> On 30/08/15 15:29, Stuart Longland wrote:
>> Just been doing some thinking with the SM-1000. There's talk of adding
>> the 700B mode to the devices, already there's the ability to switch
>> between analogue and digital.

700B in the SM1000 would be awesome.

>>
>> Other features that'd be useful include VOX and time-out timer.

> which is a work in progress: presently all it does is announce what mode
> you're in ("ANALOG", "DV" or "TONE" in Morse, 20 words a minute) as you

Provided all settings have a different first letter, one could use the
approach that some Kenwood radios used a few decades ago (TS-680 being
one IIRC) and just announce the first letter of the setting when it is
changed. So in this instance, you would get "A", "D" or "T", depending
on which mode was just selected.You might have to get a bit more
creative and have something like: "A" (analog), "T" (tone), "1" (1600),
"7" (700B).

> hit SELECT. Persistent storage of settings and the actual menu state
> machine are all that's missing.

One thing I'd like is for the SM1000 to remember the previous settings.
Mine is connected to the data port of the IC-7000 in the car. Having
it fire up in analog mode is redundant, because the radio's normal
speaker and mic can handle analog already. Having it power up in the DV
mode I'm most likely to use (say the last one I used) would be a better fit.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

[Walter Holmes]

Thanks Stuart.

I'll get some on air testing with this today.

Tnx..

Sent from my Verizon Wireless 4G LTE DROID

[Stuart Longland]

On 19/09/15 16:38, Tony Langdon wrote:
> 700B in the SM1000 would be awesome.

Well, I believe that is being worked on by others, I might have a look
at some point and see if I can help out there.

>>> >> Other features that'd be useful include VOX and time-out timer.
>> > which is a work in progress: presently all it does is announce what mode
>> > you're in ("ANALOG", "DV" or "TONE" in Morse, 20 words a minute) as you
> Provided all settings have a different first letter, one could use the
> approach that some Kenwood radios used a few decades ago (TS-680 being
> one IIRC) and just announce the first letter of the setting when it is
> changed. So in this instance, you would get "A", "D" or "T", depending
> on which mode was just selected.You might have to get a bit more
> creative and have something like: "A" (analog), "T" (tone), "1" (1600),
> "7" (700B).

Yeah, I don't want to make them too cryptic, but certainly it will be
something short. In my initial post I mentioned using "ANA", "1600",
"700". These hopefully aren't too cryptic or long.

>> > hit SELECT. Persistent storage of settings and the actual menu state
>> > machine are all that's missing.
> One thing I'd like is for the SM1000 to remember the previous settings.
> Mine is connected to the data port of the IC-7000 in the car. Having
> it fire up in analog mode is redundant, because the radio's normal
> speaker and mic can handle analog already. Having it power up in the DV
> mode I'm most likely to use (say the last one I used) would be a better fit.

That's a plan, the thought is that you pick a default power-up mode in
the settings.

[Stuart Longland]

Okay, that'll do me for this weekend. I've put up another image. This
one has the menu idea that I originally discussed:

-> Root menu:
|---> "MODE": Operating mode
| |---> "ANA": Analogue mode
| |---> "1600": FreeDV 1600
| '---> "TONE": Test tone
|
'---> "UI": User interface options
|---> "FREQ": Morse frequency
| 50-2000 Hz in 50Hz steps
|---> "WPM": Morse send speed (PARIS standard)
| 5-60 WPM in 5 WPM steps
'---> "VOL": Menu volume
1-15 units.

Image is in the same place as before.

There's a couple of application notes on the ST website regarding use of
the internal flash as an EEPROM. There's also some non-volatile
battery-backed RAM, but I suspect there's nothing to power it. I'll be
busy with other things tomorrow, so it'll be a project for next weekend.

[Tony Langdon]

On 19/09/2015 8:55 PM, Stuart Longland wrote:
> On 19/09/15 16:38, Tony Langdon wrote:
>> 700B in the SM1000 would be awesome.
>
> Well, I believe that is being worked on by others, I might have a look
> at some point and see if I can help out there.

Yes, sounded like there were rumblings in the works. :)

> Yeah, I don't want to make them too cryptic, but certainly it will be
> something short. In my initial post I mentioned using "ANA", "1600",
> "700". These hopefully aren't too cryptic or long.

1600 would be rather long, since each character is 5 elements, 2 of them
being all dahs (0), one of them having 4 dahs (1)

> That's a plan, the thought is that you pick a default power-up mode in
> the settings.
>

That would work, whether it be 1600 or 700B, I'd want it to be a DV
mode, so I don't get an earful of hash, especially if I happen to power
it up while still on an FM frequency (since the IC-7000 data port has
unsquelched audio).

[Tony Langdon]

On 19/09/2015 10:38 PM, Stuart Longland wrote:

> Okay, that'll do me for this weekend. I've put up another image. This
> one has the menu idea that I originally discussed:
>
> -> Root menu:
> |---> "MODE": Operating mode
> | |---> "ANA": Analogue mode
> | |---> "1600": FreeDV 1600
> | '---> "TONE": Test tone
> |
> '---> "UI": User interface options
> |---> "FREQ": Morse frequency
> | 50-2000 Hz in 50Hz steps
> |---> "WPM": Morse send speed (PARIS standard)
> | 5-60 WPM in 5 WPM steps
> '---> "VOL": Menu volume
> 1-15 units.

Hmm, OK. What control switches between "mode" and "UI"?

[Stuart Longland]

Okay, unit powered up, hold SELECT for a second, and it beeps. Leave
it, and it'll announce "MODE", hit SELECT or BACK momentarily then leave
it, it'll announce "UI".

Hold down SELECT at this point, you'll hear another beep. Leave it and
it'll announce "FREQ". Hit SELECT and it'll move to "WPM", or hit BACK
and it'll move to "VOL".

Basically the SELECT and BACK buttons do double duty. Momentary presses
just cycle between the options within a level, holding the SELECT or
BACK buttons down for a second SELECTS or BACKS out.

So supposing you found the audio prompts a little loud, to turn it down
it'd be a case of:

1. Long-press SELECT: enter menu
2. Short-press either SELECT or BACK: move to "UI" (there are only two
options right now, so either one works)
3. Long-press SELECT: enter UI
4. Short-press BACK: move to "VOL" (OR; short-press SELECT twice)
5. Long-press SELECT: enter VOL
6. Use short presses of SELECT and BACK to adjust the volume
7. Long-press SELECT: confirm VOL, we're now back in the "UI" menu
8. Long-press BACK: exit "UI", we're now back at the root menu
9. Long-press BACK: exit the menu altogether

A little clumsy, but given we've only got two buttons, I figured this
was better than just having one button to increment and the other to
select. I had a bicycle tail light like that (single button that just
cycled lots of modes) and it drove me mad.

[Matthew Cook]

Ok.. can I ask why people/hams get fixated on using morse for UI feedback?

There are a very limited number of people that are proficient in such things now days.  

You have a micro with a brain the size of a planet along with an excellent codec at your disposal, so why not take advantage of it.

I would have thought a cool and geeky method of Menus would be to digitise voices using **codec-2** and simply play them back.  Right now 4s of voice for each menu item would require 6400 bits or about 800 bytes on a SM1000.   With 10 or so messages in your menu a total of 8kB.

I don't believe we're lacking for space in the SM1000, happy to be corrected here.  There are plenty of bin file to C array conversion utilities available these days, so embedding such things is now trivial.

As a person who spends all day every day writing UI's limited to one LED and one switch, why are we limiting the SM1000 by using morse?   The opportunity to do something cool and geeky (ie actually use codec2 for the menus) shouldn't be lost.

Just my 0.02c worth sans GST.

73

Matthew

VK5ZM

[Stuart Longland]

On 21/09/15 09:57, Matthew Cook wrote:
> Ok.. can I ask why people/hams get fixated on using morse for UI feedback?
>
> There are a very limited number of people that are proficient in such
> things now days.
>
> You have a micro with a brain the size of a planet along with an
> excellent codec at your disposal, so why not take advantage of it.
>
> I would have thought a cool and geeky method of Menus would be to
> digitise voices using **codec-2** and simply play them back. Right now
> 4s of voice for each menu item would require 6400 bits or about 800
> bytes on a SM1000. With 10 or so messages in your menu a total of 8kB.
>
> I don't believe we're lacking for space in the SM1000, happy to be
> corrected here. There are plenty of bin file to C array conversion
> utilities available these days, so embedding such things is now trivial.

We can.
We will.
Not yet.

This was discussed here:
https://groups.google.com/d/msg/digitalvoice/-0ofbbl8mtQ/-tipqWlQCQAJ

I can code up a tool that will take a binary file and generate a C array
from it. Been there, done that. Coding up something that passes
samples through Codec2 from some source? Again, shouldn't be hard, I'm
effectively generating tones from a hardcoded PCM sample of a sine wave.
I did it with plain PCM on an ATMega32U4 previously.

HOWEVER: The menu is in a significant state of flux right as of now.
What has been discussed is an initial stab at a possible menu structure
and layout.

Using Morse now meant I could bash out a quick module that would "do the
job" for now, and move on. Morse code is widely understood, easy to
implement, and doesn't occupy much space.

If I add a new menu item or change a name, I simply add a new string in,
I don't have to faff around with a sound recording program making the
raw recording, encoding it as Codec2, stuffing it into a byte array,
then interfacing it.

The code I download to the device is also smaller, meaning re-flashing
the SM1000 is faster and so I can test more in an afternoon.

Once voice prompts are implemented, we can leave the Morse UI there, and
if someone prefers a Morse UI, they can select it, the default being a
voice UI.

I consider this "learning to crawl before attempting to walk".

I have *never* coded anything for the SM1000 prior to this last weekend,
nor have I done any significant Codec2/FreeDV work. I have to learn how
the code is structured to figure out where ideas can fit in.

If my efforts are insufficient thus far I can stop now if you like.

Whilst I'm here, yes, I'm all for hardware improvements. A small LCD
and keypad would have been great. (e.g. having the SM1000 double as a
DTMF keypad would be awesome.) I'm getting a couple of emails privately
suggesting this as an improvement.

Agree 100%.

HOWEVER, gcc doesn't ship with a -mgimmie-a-lcd, nor can I do a #include
<keypad.h> and have the firmware make the existing SM1000s out there
magically sprout a keypad and LCD. A future descendent of the SM1000
might have these features, but I'm the wrong person to ask here. I
didn't do the hardware design, and don't have the facilities to produce
one. I can only make **software** changes to the device.

I'm after feedback on how the UI can be improved in software, and yes,
voice has been noted as a future improvement and has always been on the
road map.

Similarly, persistent storage, is on the road map. In fact, that will
probably be next weekend's effort. No point in having configuration
settings if it keeps forgetting them.

Long term, using CDC-ACM to provide a UI via a virtual serial port is
also worthwhile (e.g. hamlib integration).

We'll get there.

[David Rowe]

Hi Matt,

Yes I think Stuart indicated in another post that he'll be moving the
voice prompts. Morse is just a way to get started, get his head around
the SM1000, build a UI framework etc.

Some more on this on the codec2-dev list over the weekend.

Limited vocab voice rec (numbers and a few words) is also a possibility,
the model parameters Codec 2 extracts could be compared against templates.

"Change mode to 700B"

A free SM1000 to the first person who can make it do this when I speak
to it:

David: "Open the pod bay doors SM1000"
SM1000: "I'm sorry I can't do that Dave"

Cheers,

David

On 21/09/15 09:27, Matthew Cook wrote:
> Ok.. can I ask why people/hams get fixated on using morse for UI feedback?
>
> There are a very limited number of people that are proficient in such
> things now days.
>
> You have a micro with a brain the size of a planet along with an
> excellent codec at your disposal, so why not take advantage of it.
>
> I would have thought a cool and geeky method of Menus would be to
> digitise voices using **codec-2** and simply play them back. Right now
> 4s of voice for each menu item would require 6400 bits or about 800
> bytes on a SM1000. With 10 or so messages in your menu a total of 8kB.
>
> I don't believe we're lacking for space in the SM1000, happy to be
> corrected here. There are plenty of bin file to C array conversion
> utilities available these days, so embedding such things is now trivial.
>
> As a person who spends all day every day writing UI's limited to one LED
> and one switch, why are we limiting the SM1000 by using morse? The
> opportunity to do something cool and geeky (ie actually use codec2 for
> the menus) shouldn't be lost.
>
> Just my 0.02c worth sans GST.
>
> 73
>
> Matthew
> VK5ZM
>
> On 19 September 2015 at 23:04, Stuart Longland

> <mailto:digitalvoice%2Bunsu...@googlegroups.com>.

> To post to this group, send email to digita...@googlegroups.com

> <mailto:digita...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/digitalvoice.
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "digitalvoice" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to digitalvoice...@googlegroups.com

> <mailto:digitalvoice...@googlegroups.com>.

> To post to this group, send email to digita...@googlegroups.com

> <mailto:digita...@googlegroups.com>.

[Matthew Cook]

David & Stuart,

No problem.  I'll wait for the voice version to become available before testing or providing any further feedback or patches.  You both seem to have the final end game covered nicely.

Stuart I simply read the post that I responded too at face value (without having read all 14 previous comments again from the start), and trust that you now understand from what context my response originated, which wasn't intended to offend.  I'll refrain from jumping in on your posts in future.  However I beg to differ that "Morse is widely and easily understood" and stand by my original comments, best we just simply agree to disagree; enough said.

David I've got enough software projects to keep me busy without any SM1000 challenges.  I'll be there when you want a hand porting the 700C mode to the SM1000.  All I can offer right now is a basic "Shall we play a game" playback routine that I knocked up to prove my VM & SM1000 cross compiling tool chain was working.

73

Matthew

VK5ZM

To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.
To post to this group, send email to digita...@googlegroups.com.

[Tony Langdon]

On 21/09/2015 9:57 AM, Matthew Cook wrote:
> Ok.. can I ask why people/hams get fixated on using morse for UI feedback?

I think the question has been answered, it's simple. For me, I actually
prefer the simpler feedback, I can process it (in my head) as separate
to speech coming through the system, and short Morse characters (like
the single character prompts I suggested) occupy less speaker time than
voice. The length of time voice prompts need to be often result in me
having to remember the menu structure in its entirety, and navigating
that (as is the case with the answering machine here) gives a stuttering
effect, as the speech starts, then I do the next button press from
memory. :)

The narrow band pure tone is also easier for my ears and brain to "grab"
in a short time, compared to voice. Some speech can take a significant
fraction of a second or longer for me to interpret, so it would have to
be the right voice to minimise that risk. While my ability to read long
strings of Morse is limited, short bursts are almost instantly recognised.

Conclusion, both voice and Morse prompts should be offered in the "UI"
menu. Each suits different people.

[Stuart Longland]

Hi Matthew,

On 21/09/15 12:14, Matthew Cook wrote:
> Stuart I simply read the post that I responded too at face value
> (without having read all 14 previous comments again from the start), and
> trust that you now understand from what context my response originated,
> which wasn't intended to offend. I'll refrain from jumping in on your
> posts in future.

No biggie. There were a few questioning some decisions, and I figured
I'd make it clear where I was heading.

Certainly if there were alternate ideas as to how to map button presses
to actions or how to lay out the menu structure so as to make settings
easier to find, I'm all ears.

> However I beg to differ that "Morse is widely and
> easily understood" and stand by my original comments, best we just
> simply agree to disagree; enough said.

Well, not as "widely understood" as spoken language, granted. However,
infinitely more widely understood than a code of my own devising.

That is the point I'm making. Not everybody knows it now, but there's
*loads* of material explaining how to decode it. Given long-term use of
such a UI, people would probably soon learn to decode enough Morse to be
able to use it proficiently.

Tony makes a good point about the ability to recognise a tone. It takes
a bit of time to "tune in" to Codec2, and so one may not as easily be
able to understand a voice depending on the acoustic environment they're
in at the time.

I think it's going to be a horses for courses scenario. The fact that
we've gone for an audio-based UI rather than a visual (text/LED) one
should be a big winner with the visual-impaired segment of the amateur
community, irrespective of whether it's voice or Morse.

Regards,

[Paul Warren]

I'll volunteer to be the voice of the SM1000. I've done voice recordings for announcements and IVRs for my previous employer, but no other voiceover creds :)

--
You received this message because you are subscribed to the Google Groups "digitalvoice" group.

To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.
To post to this group, send email to digita...@googlegroups.com.
Visit this group at http://groups.google.com/group/digitalvoice.
For more options, visit https://groups.google.com/d/optout.

--

Paul Warren
p dot a dot warren at gmail dot com
pwarren.id.au

[Stuart Longland]

On 23/09/15 20:12, Paul Warren wrote:
> I'll volunteer to be the voice of the SM1000. I've done voice recordings
> for announcements and IVRs for my previous employer, but no other
> voiceover creds :)

That would be fantastic. I don't have anything for you just now, but
soon as we get the necessary code in place to play back voice prompts,
we'll let you know.