<div dir="ltr">And by the way great job!!!<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-10 17:57 GMT-05:00 Pierre Martel <span dir="ltr"><<a href="mailto:petem001@gmail.com" target="_blank">petem001@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Will the hardware headers will be available with that release ?? (the i/o pin on both the BBB and rpi) so that we could use a simple dongle without mods and input/and outpu connection could be driven directly to the embeded device?<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">2016-01-09 14:44 GMT-05:00 Doug Crompton <span dir="ltr"><<a href="mailto:doug@crompton.com" target="_blank">doug@crompton.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">


<div><div dir="ltr">


<div dir="ltr"><font face="Tahoma,sans-serif">I am pleased to announce that version 1.3 of the BBB and RPi2 images are now in Alpha testing. The 1.3 versions will bring the BBB and RPi2 to the same level of updates and code capability. This update will also mark a split in the code. The 1.x versions will continue with maintenance updates as needed but a new 2.x version will be appearing in 2016. The 2.x versions will mark a very significant branch from the current code including a completely different code concept and many new features and capabilities. More on that will be coming out soon. The 1.x versions are considered stable and will be supported into the future during transition to the 2.x code. Here is a list of significant changes for version 1.3 -</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">Both the BBB and RPi2 have been updated to 4.x kernels and all associated software has been updated.</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">New app_rpt.c changes:</font><font face="Tahoma,sans-serif"><br></font><div><font face="Tahoma,sans-serif"> </font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"> - Removed obsolete uchameleon code (about 2500 lines).</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">      <br>      This is obsolete hardware.</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"> - Added COS timeout, with COS flap suppression (new rx_timeout, rx_cosflap  rpt.conf parameters)</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">      This is an attempt at eliminating single node hangups of connected networks. Often a single node,</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">      due to radio or interface failure, can cause a COS hangup tying up an entire network. If the timeout<br>      is set COS is monitored and the indication of asserted COS to the network is dropped if the time is<br>      exceeded. The COS timeout is</font><font face="Tahoma,sans-serif"> set in the same way as a TX timeout. The COS </font><font face="Tahoma,sans-serif">unasserted indication to<br>      the network will remain until the hardware COS is cleared. COSFLAP can also be set and will attempt<br>      to catch conditions where a squelch is </font><font face="Tahoma,sans-serif">"flapping" by not resetting the timer during this condition and<br>      allowing the timeout period to proceed. </font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"> - Added telemetry gain levels (new telemnomdb rpt.conf parameter)</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">     This will allow a level adjustment of telemetry (connect, disconnect, etc.) messages. The level </font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">     change is in dB like the Echolink level adjustments. This will eliminate the need to change the</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">     level of audio files. </font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"> - Added telemetry ducking (AKA: Allison ducking) (new telemduckdb rpt.conf parameter)</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">    This optionally reduces telemetry levels when a voice signal is present. </font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"> - Changed tx timeout variable name from totime to tx_timeout (the old variable is deprecated,</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   </font><font face="Tahoma,sans-serif"> but still works after printing a console warning)</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"> <br>    This was done to avoid the confusion between TX and RX timeouts. TX timeout is applied only<br>    to the local transmitter. It is often in addition to a TX timeout that is set at a longer time in the<br>    radio itself ensuring double protection for a hung transmitter. The RX timeout, added in this<br>    update, would normally be set slightly longer than the TX timeout to offer the same protection <br>    to the network from a COS hardware failure. <br>      <br></font><font face="Tahoma,sans-serif">New core Asterisk changes:</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">- Removed need to recompile to enable/disable RADIO_RELAX</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   This command when on reduces the DTMF decode requirements but can also cause DTMF "Falsing"<br>   RADIO _RELAX is OFF by default and has been in ALL BBB and RPi2 compiles.  This command</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   previously required a menuselect change and recompile to enable. It is now added as a runtime</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   option in the simpleusb.conf and usbradio.conf files.</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   IMPORTANT NOTE - this command should be used with caution and NEVER used indiscriminately.</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   It loosens the  DTMF decoding requirements but also can cause voice "falsing" which can severely</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   effect the audio. The "falsing" causes muting that sounds like dropouts. In 99.9% of cases you do<br>   not need to enable this</font><font face="Tahoma,sans-serif"> command. Proper pre/de-emphasis and level settings solve most all DTMF <br>   problems and should always be the first thing tried. I have run with this off in all the time I have<br>   used Allstar and never had a problem. In all but one case so far, that I know of, using the<br>   BBB/RPi2 images DTMF issues have been solved with proper settings. So be aware that this<br>   command can potentially cause as many problems as it might solve. <br><br></font><font face="Tahoma,sans-serif"></font><font face="Tahoma,sans-serif"></font><font face="Tahoma,sans-serif"> New chan_simpleusb.c changes:</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"> - Added code to resolve annoying variable transmitted audio delay</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   This has plagued simpleusb on all platforms since it was added to the ACID code. It is more prevalent<br>   on the small</font><font face="Tahoma,sans-serif"> boards and especially the RPi2.  The symptoms generally only appear when Allstar<br>   is used on a</font><font face="Tahoma,sans-serif"> repeater. A user would hear their own voice for a few syllables or a word after<br>   unkeying. This</font><font face="Tahoma,sans-serif"> update totally fixes the problem and the delay through the system is now constant<br>   and short in </font><font face="Tahoma,sans-serif">length.</font><font face="Tahoma,sans-serif">   </font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br>   The delay elimination update has been in beta testing on several repeaters for the last month <br>   with excellent results.<br><br></font><font face="Tahoma,sans-serif">Other updates<br><br> - Cleaned up all compiler warnings. in app_rpt.c and chan_simpleusb both now compile cleanly,</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   no warnings at all.  Added flags to allow compiles using new gcc for new and old versions of the</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">   code</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif"> - The weather scripts are updated to "work around" the loss of Google voice.<br><br> - With the kernel update the BBB now has GPIO capability for external control like the RPi2. <br></font><font face="Tahoma,sans-serif"></font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">While these are the significant changes in 1.3 there are other programs and scripts added and updated.</font><font face="Tahoma,sans-serif"><br></font><font face="Tahoma,sans-serif">There may be more options added and further updates before the release date and a complete listing<br>will be available at that time.</font><br><br><font face="Tahoma,sans-serif">Many thanks to Dave, KB4FXC and Chris, W0ANM for these updates.<br><br>I am hoping we can move this to distribution by the end of January early February time frame.<br><br>73, Doug <br>WA3DSP<br><br></font><br></div></div>
                                          </div></div>
<br></div></div><span class="">_______________________________________________<br>
<br>
arm-allstar mailing list<br>
<a href="mailto:arm-allstar@hamvoip.org" target="_blank">arm-allstar@hamvoip.org</a><br>
<a href="http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar" rel="noreferrer" target="_blank">http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar</a><br>
<br>
Visit the BBB and RPi2 web page - <a href="http://hamvoip.org" rel="noreferrer" target="_blank">http://hamvoip.org</a><br></span></blockquote></div><br></div>
</blockquote></div><br></div>