From: ke6txy@gmail.com   
      
   Hi everyone,   
      
   I've been working on a project for a while that other people might find   
   interesting and wanted to see if anyone had any ideas for improvements,   
   etc.   
      
   It's basically an autopatch, but with a difference: it bridges to and   
   from USENET as opposed to the PSTN.   
      
   The idea is pretty simple: check a newsgroup for new messages, key up   
   the transmitter (which is tuned to a local 2m repeater frequency) when   
   it downloads them, and read the messages out using text-to-speech.   
   Everything runs on a Raspberry Pi, so is very simple (and cheap!) to   
   build.   
      
   One of the neat things is that even though it reads the messages out as   
   phone, it can pretty easily be tweaked to do CW or even data modes if   
   you'd like.  I've kept it phone for now because it's easier for testing   
   purposes, but have confirmed that CW is easily possible.  For anyone   
   preferring a data mode, PSK31 Hellschreiber will likely be the standard   
   in that regard, but that still needs to be decided upon - though   
   technically just about any data mode (including SSTV!) could be used.   
      
   Right now, attention is being focused on the repeater-to-USENET portion   
   of the system.  It's relatively simple to read out USENET messages over   
   a repeater, but bridging a phone transmission to USENET is rather more   
   challenging.   
      
   As I'm sure everyone has figured out by now, the big issue is reliably   
   processing speech into text.  This is made more difficult by the   
   inherently interference-prone nature of radio transmissions, which are   
   really good at confusing speech recognition systems when conditions   
   are QRMing phone messages.   
      
   The other issue is how well a Raspberry Pi can process that speech data   
   once the data is received.  This isn't so much a case of the Pi not   
   having the horsepower to be up to the job (a 3B does just fine running   
   Jasper for this purpose), but rather that a speech-processing backend   
   that is heavily-rooted in machine learning and mass aggregation of   
   speech data for analysis is typically going to be *far* superior in   
   terms of accuracy in comparison to a standalone system doing what   
   basically amounts to static analysis on each received transmission.   
      
   To that end, consideration is being given to integrating a cloud-based   
   speech recognition service (Google's Speech-to-Text API, Amazon's   
   Transcribe, or IBM's Watson equivalent are all being considered) as a   
   supplement to Jasper.  The obvious downside is that this is dependent   
   on having an always-available Internet connection, but in cases where   
   operation from a static location with decent connectivity is an option   
   it would be advantageous.   
      
   Also, I'm aware that using these cloud-based services introduces lag in   
   terms of how long it takes to send the data to them for processing and   
   receive it back.  That, unfortunately, is inherent to the design and   
   can't really be worked around.  However, given the method by which   
   and nature of how communication on USENET takes place, I don't feel   
   that this is a significant issue.   
      
   There are some additional features that I'd like to add in the future:   
   more direct Echolink / WIRES integration; remote control of the gateway   
   so that you can do things like choose the newsgroup to hear messages   
   from or post messages to; scraping of APRS data to geotag posts...   
   And a couple of others.  But right now I just need to get basic two-way   
   functionality going.   
      
   So there it is!  All of this spawned from wanting a way to be able to   
   keep up with rec.radio.amateur.misc without needing an active data   
   connection to do so.  Let me know your thoughts!   
      
   73, KETXY Dave   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)