fdv translation any language

[Jose Donnari]

Hello friends, just to present this video where we explain how easy it is to translate from any language to another without any problem, you no longer need to speak in foreign languages, you can speak in your native language and translate instantly. We await any questions at your disposal.

jose LU5DKI

[Thomas Hall, Ph.D.]

Hi, Jose-

Looks fascinating! Video is only 41 seconda long- can you link to the entire thing and to documentation?

73,

Tom

On Sun, Oct 12, 2025 at 2:47 PM Jose Donnari <lu5...@gmail.com> wrote:

Hello friends, just to present this video where we explain how easy it is to translate from any language to another without any problem, you no longer need to speak in foreign languages, you can speak in your native language and translate instantly. We await any questions at your disposal.

jose LU5DKI

--
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 view this discussion visit https://groups.google.com/d/msgid/digitalvoice/5c92cf06-6af8-4e0e-b487-3b34f364b6b7n%40googlegroups.com.

[Art Botterell]

OK, so this is interesting.  How might we manage such a capability?  

My intuition is that this might be supported by a convention on how to format the existing (and future expanded) data subchannel.  In addition to station ID and perhaps grid square, maybe include a source-language code?

I can also imagine a protocol by which two stations might automatically negotiate a QSY frequency to help free up the calling frequency.  DV ALE, anyone?

I’m quite ignorant about this stuff yet, so please let me just ask… what’s the current thinking on the use of sub-channel data?

73

Art KD6O

On Oct 12, 2025, at 11:47, Jose Donnari <lu5...@gmail.com> wrote:

Hello friends, just to present this video where we explain how easy it is to translate from any language to another without any problem, you no longer need to speak in foreign languages, you can speak in your native language and translate instantly. We await any questions at your disposal.

jose LU5DKI

--
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 view this discussion visit https://groups.google.com/d/msgid/digitalvoice/5c92cf06-6af8-4e0e-b487-3b34f364b6b7n%40googlegroups.com.

<VID-20251012-WA0007.mp4>

[Mooneer Salem]

Hi Art,

Currently we're using the data just for the user's callsign (for use with i.e. FreeDV Reporter). There aren't any plans to include anything additional due to the extremely low bandwidth available, unfortunately.

Thanks,

-Mooneer K6AQ

To view this discussion visit https://groups.google.com/d/msgid/digitalvoice/C50CE299-0BF7-42DD-9F71-48451D983ACA%40botterell.net.

[Walter Holmes]

There is currently the QSY request capability built into the FreeDV reporter page. The one that comes up inside the client software.

 

Granted, this is not over RF, but it certainly works if your connected to the Internet, as 99.9% of us are.

 

 

Walter/K5WH

To view this discussion visit https://groups.google.com/d/msgid/digitalvoice/C50CE299-0BF7-42DD-9F71-48451D983ACA%40botterell.net.

[Art Botterell]

Mooneer and All,

It’s crucial, certainly, to maintain focus on the immediate task, and I may be dancing ahead of the music by suggesting that meta-data will be required to make the most of FreeDV (the existence of FreeDV Reporter seems like evidence in that direction.)  Still, I have a strong intuition, fueled by some amount of experience and a bit of imagination, that additional layers of the protocol will be wanted.  

Dependence on the Internet is great for bootstrapping, but it hardly seems like an ultimate hams-for-hams solution.  Otherwise I’m afraid we’ll need to wrap FreeDV with some additional over-the-air data.  FreeDV Reporter is great, but may we not imagine richer applications?

Can I assume that the callsign is being compressed and/or encoded?  If so, by what algorithm and how large is a callsign when compacted?

I guess what I’m really asking is, where might I read the spec?  And what’s the long-term plan for its evolution?

73,

Art KD6O

To view this discussion visit https://groups.google.com/d/msgid/digitalvoice/CAAzDfxOjg5st3ZJgg6LK_TgssUX-%2B8buDYZ20H%2B78UUvL0PccA%40mail.gmail.com.

[Mooneer Salem]

Hi Art,

There hasn't been a formal specification written (yet) but basically, we use LDPC(112,56) to encode 56 bits of data with an additional 56 bits of parity. With a six bit character set as follows:

// 0: ASCII null
// 1-9: ASCII 38-47
// 10-19: ASCII '0'-'9'
// 20-46: ASCII 'A'-'Z'
// 47: ASCII ' '

This means 8 characters maximum. (See https://github.com/drowe67/freedv-gui/blob/master/src/pipeline/rade_text.c for how this is implemented in practice.) This encoding was originally used with the older FreeDV modes and was chosen to ensure we showed *something* to the user in a reasonable amount of time (note 25 bits/sec maximum per https://github.com/drowe67/codec2/blob/main/README_freedv.md). I wouldn't expect much faster bitrates in the data channel for RADEV2, unfortunately. Hopefully this helps add some context to why the data channel transmits what it does.

Thanks,

-Mooneer K6AQ 

To view this discussion visit https://groups.google.com/d/msgid/digitalvoice/3E677336-7B7F-47F2-B550-26257DEED76B%40botterell.net.

[Art Botterell]

Thanks, Mooneer!

So… given that the team has already gotten net bandwidth substantially below that for analog SSB, I’m wondering what the cost would be to increase the text rate in RADEv3?

My thought is this:  Many potential applications will require some amount of machine-readable meta-data.  (By which I mean an as-yet undefined collection of “tags” including sender callsign, but also such items as grid coordinates, QSY frequencies or deltas, control flags for remote functions, language identifiers, and the other stuff we may not have thought of yet.)  Such data could be transmitted in-band as part of the FreeDV stream, or out-of-band with a separate data carrier, or by accepting a dependency on Internet connectivity.

Certainly I understand the need to maintain focus in the near term on voice quality and signal robustness, but for the longer term I’d suggest that transmitting metadata be treated as another core function.  My question, I guess, is whether it would be better in the long run to make an expanded text channel within FreeDV, or to wrap FreeDV in another layer of encoding to implement an out-of-band control channel.  I can see valid arguments both ways, but personally a wrap-around solution strikes me as maybe a bit awkward for implementers.

As hams we’re unaccustomed to dealing with machine-readable metadata (CTCSS codes might be an exception to that.)  But in digital architectures such signaling is hard to avoid, and it’s frequently essential to application-level flexibility and control/scalability.

That’s why I’d urge that the team consider investing some fraction of our bandwidth savings in expanding the data sub-channel.  Or at least standardizing an out-of-band over-the-air mechanism for synchronous metadata transmission.  As a practical goal I’d suggest, as a point of departure for discussion, a net text rate on the order of four times the current speed… call it 100 bits per second… allowing a callsign to complete in, what?, two seconds?  (And also I’d suggest the metadata block should loop continually during transmission, if it doesn’t already.)

Is that impossible, do you think?

73,

Art KD6O

To view this discussion visit https://groups.google.com/d/msgid/digitalvoice/CAAzDfxMW2njmTJfitwREqrypLdSXHQGqMmdN2dYtcHL9cMmOCQ%40mail.gmail.com.