<HTML><HEAD>
<STYLE><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></STYLE>
</HEAD>
<BODY class=hmmessage dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>I have about 7 moded fob..</DIV>
<DIV> </DIV>
<DIV>I have no problem with it..</DIV>
<DIV> </DIV>
<DIV>I was talking about friends that are not able to do it.. </DIV>
<DIV> </DIV>
<DIV>I did offer to do it for them. But they want to work on something they will
be able to fix it it break..</DIV>
<DIV> </DIV>
<DIV>And As other stated .. we have now more blob the real chip in our fobs..
</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<DIV style="FONT: 10pt tahoma">
<DIV> </DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A title=doug@crompton.com
href="mailto:doug@crompton.com">Doug Crompton</A> </DIV>
<DIV><B>Sent:</B> Sunday, January 10, 2016 11:35 PM</DIV>
<DIV><B>To:</B> <A title=arm-allstar@hamvoip.org
href="mailto:arm-allstar@hamvoip.org">ARM Allstar</A> </DIV>
<DIV><B>Subject:</B> Re: [arm-allstar] Update version 1.3 BBB/RPi2 now in
testing</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<DIV dir=ltr><FONT color=#000000
face=Tahoma,sans-serif>Pierre,<BR><BR> Have you looked at the
simpleusb FOB mod on the web site? The method of threading the wire under
the pins and bending over the stripped end and tacking is SO easy. That is the
ONLY surface mount soldering you have to do and <BR id=FontBreak>I would not
call that surface mount soldering but rather soldering to a surface mount pin. I
invite anyone to get the proper materials and tools and try it. It takes but a
second to tack the wire on. Get a board ($3) and practice!</FONT><BR><FONT
face=Tahoma,sans-serif><BR></FONT><FONT face=Tahoma,sans-serif>As far as
external control, the GPIO pins on the main board are good for that. Depending
on what you want to control you can use very inexpensive relay boards
designed to connect directly to the GPIO or a USB GPIO interface. Both ways are
described on the hamvoip.org web page in the how-to section.
</FONT><BR><BR><B><FONT style="FONT-SIZE: 16pt" size=4>73 Doug</FONT><FONT
style="FONT-SIZE: 16pt" size=4><BR></FONT><FONT style="FONT-SIZE: 16pt"
size=4>WA3DSP</FONT><FONT style="FONT-SIZE: 16pt" size=4><BR></FONT><FONT
style="FONT-SIZE: 16pt" size=4>http://www.crompton.com/hamradio</FONT></B><FONT
style="FONT-SIZE: 16pt" size=4><BR></FONT><BR><BR>
<DIV>
<HR id=stopSpelling>
Date: Sun, 10 Jan 2016 20:01:28 -0500<BR>From: petem001@gmail.com<BR>To:
arm-allstar@hamvoip.org<BR>Subject: Re: [arm-allstar] Update version 1.3
BBB/RPi2 now in testing<BR><BR>
<DIV dir=ltr>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>I do understand that we need to be carefull with the gpio cause when they
are gone they are gone for good. but you have to understand that soldering on
those small pins are not for everyone.. I have a few friends that are
waiting to jump in when the gpio will work cause they dont have the skill to
solder those pin and no one around to do it. for them..<BR><BR></DIV>On the
other end, It will cost a bit more to work a nice circuit on the gpio, but all
can be done with normal componant ( non surface mount) on a small pcb where we
could have nice connector for wiring that goes to the radio's they could already
be choice for high or low squelch input. and othe such thing.. <BR><BR></DIV>One
other thing could be the use of a way to have a serial connection with pin 8 and
10 on the header that could be used for control of a remote base.. (wishfull
thinking) ;-) <BR><BR></DIV>so someone could design a nive pcb with all those
option and this would be very fun to work
with!<BR><BR></DIV>Pierre<BR></DIV>VE2PF<BR>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV><BR><BR><BR><BR></DIV></DIV></DIV></DIV></DIV></DIV>
<DIV class=ecxgmail_extra>
<DIV> </DIV>
<DIV class=ecxgmail_quote>2016-01-10 18:59 GMT-05:00 Doug Crompton <SPAN
dir=ltr><<A href="mailto:doug@crompton.com"
target=_blank>doug@crompton.com</A>></SPAN>:<BR>
<BLOCKQUOTE class=ecxgmail_quote
style="PADDING-LEFT: 1ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<DIV dir=ltr><FONT color=#000000 face=Tahoma,sans-serif>Perre,<BR><BR>
Not promising anything but yes they might be. But be aware - I have said this
many times before - the job of modifying a FOB and the interface circuitry
involved is little more than what you would have to do to use the main board
GPIO. You would still need to build the same interface circuitry. The only
thing you would not have to do is solder a few wires on the FOB. <BR><BR>I
really wish I could get people to understand how ridiculously easy that is and
how the GPIO method is not just connect a couple of wires up to pins. It is
much safer and cleaner to work on a $3 FOB then to build circuitry and run
wires to GPIO on the main board. You can buy a dozen FOBS for $24 - less than
the cost of one RPI2 board. Practice on a couple, if you blow them up throw
them in the trash and start over, no big loss.<BR><BR>I realize there are some
hams due to disability, eyesight, etc. who would not be able to do the
modification but in that case I doubt you would be able to build the required
interface to the main board GPIO either. Most hams know other hams. Ask
someone to help you.<BR></FONT><FONT face=Tahoma,sans-serif><BR></FONT><FONT
face=Tahoma,sans-serif>The simple FOB modification is at the <A
href="http://hamvoip.org" target=_blank>hamvoip.org</A> web
page.</FONT><BR><BR><B><FONT style="FONT-SIZE: 16pt" size=4>73
Doug</FONT><FONT style="FONT-SIZE: 16pt" size=4><BR></FONT><FONT
style="FONT-SIZE: 16pt" size=4>WA3DSP</FONT><FONT style="FONT-SIZE: 16pt"
size=4><BR></FONT><FONT style="FONT-SIZE: 16pt" size=4><A
href="http://www.crompton.com/hamradio"
target=_blank>http://www.crompton.com/hamradio</A></FONT></B><FONT
style="FONT-SIZE: 16pt" size=4><BR></FONT><BR><BR>
<DIV>
<HR>
Date: Sun, 10 Jan 2016 17:57:05 -0500<BR>From: <A
href="mailto:petem001@gmail.com" target=_blank>petem001@gmail.com</A><BR>To:
<A href="mailto:arm-allstar@hamvoip.org"
target=_blank>arm-allstar@hamvoip.org</A><BR>Subject: Re: [arm-allstar] Update
version 1.3 BBB/RPi2 now in testing
<DIV>
<DIV class=h5><BR><BR>
<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>
<DIV> </DIV>
<DIV>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>
<BLOCKQUOTE style="PADDING-LEFT: 1ex; BORDER-LEFT: #ccc 1px solid">
<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>_______________________________________________<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></BLOCKQUOTE></DIV>
<DIV> </DIV></DIV><BR>_______________________________________________
arm-allstar mailing list <A href="mailto:arm-allstar@hamvoip.org"
target=_blank>arm-allstar@hamvoip.org</A> <A
href="http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar"
target=_blank>http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar</A>
Visit the BBB and RPi2 web page - <A href="http://hamvoip.org"
target=_blank>http://hamvoip.org</A></DIV></DIV></DIV></DIV></DIV><BR>_______________________________________________<BR><BR>arm-allstar
mailing list<BR><A
href="mailto:arm-allstar@hamvoip.org">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></BLOCKQUOTE></DIV>
<DIV> </DIV></DIV><BR>_______________________________________________
arm-allstar mailing list arm-allstar@hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar Visit the BBB and
RPi2 web page - http://hamvoip.org</DIV></DIV>
<P>
<HR>
_______________________________________________<BR><BR>arm-allstar mailing
list<BR>arm-allstar@hamvoip.org<BR>http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar<BR><BR>Visit
the BBB and RPi2 web page - http://hamvoip.org</DIV></DIV></DIV></BODY></HTML>