Re: I2C issue

Jon Greene

Thanks Tadd for that information,

So today I went up the mountain and shut off all 4 of the radio's, then even though I didn't have to do it but, did a factory reset of the PiTNC's, then one by one redid the I2C settings from setting the I2C address then the TXDelay setting.

So after got all 4 of the PiTNC set, and then restacked.  I then still had the radio's off and rebooted, then checked the I2C and they had kept there settings, so then I turned the radio's back on and everything started to work.

Then I restarted to pi to see if when we remotely reboot the pi that everything would still work.  So after rebooting the pi with the radio's turned on, I then used the i2cdetect -y 1 and non of the 4 PiTNC were on the list, and the radio program wasn't even running. Yet I still did a pitnc_getparams 1 6 (for one of the PiTNC) and it was showing address of 0 and TXDelay of like 40.  

So after I saw that I shut the pi off, turned the radio's off, rebooted the pi and then did a i2cdetect -y 1 and it had all 4 of the PiTNC address.  So does anyone know of a way to either have the radio's stay on and not cause issues, or should I try to get relays that can turn the radio's off when the pi shuts down, and when it reboots waits a certain amount of time like 1 minute before it turns the radio's on.


On Friday, July 20, 2018 10:35 AM, Tadd KA2DEW in NC via Groups.Io <tadd@...> wrote:

  The TNC-PI has the ability to return trash from PITNC-get if it is receiving data from a radio.  I don’t know if this is what is happening for you but it seems to have better dialogs with the PITNC programs if the radio receiver is disconnected. 
  One way to know that PITNC-get is showing you garbage, is to look at the returned I2C address register, register #7.  If it doesn’t match what you know the I2C address is, then you are getting garbage.  
  Sending a reset to the TNC, PITNC-set 0 0 register 15, data 2, will clear out all that, but if you are hooked to an active receiver, it’ll get garbage again, sometimes.  I’m not clear on what the mechanism there, just that’s what it looks like to me. 
  The TXdelay can be written in the registers, like you are doing, but setting it via the Potentiometer seems to be more reliable.  I don’t know why.  You can program G8BPQ via the config to write a TXDELAY of 0 to the KIS parameters, I think.  Then the potentiometer on the TNC-PI will have control of the TXDELAY.  
  This is what I use for a point to point dedicated link on our network.  
Notice the TXDELAY=0 and the KISSOPTIONS.  

PORTNUM=1        ; Optional but sets port number if stated
ID=p2p link to W1AW-4     ; Displayed by PORTS command
TYPE=I2C         ; Port is RS232 Com or I2C Com
PROTOCOL=KISS    ; TNC is used in KISS (or JKISS) mode
;;;;;;KISSOPTIONS=PITNC,NOPARAMS  ;; don’t set NOPARAMS.  we want params.  
I2CBUS=1         ; 0 for Version 1 board, 1 for Version 2 board. Don't include this for RS232/USB TNCs
I2CDEVICE=6      ; Decimal I2C device-ID --  Don't include for RS232/USB TNCs
;                ; See ..\RelatedFiles\KissRoms\
FULLDUP=0        ; Only meaningful for KISS (or JKISS) devices
; IOADDR=1       ; 1 = SERIAL PORT COM1 ETC.  << do not use if TYPE=I2C
SPEED=19200      ; RS232 COM PORT SPEED
CHANNEL=A        ; A for single channel TNC, A or B for multichannel
PERSIST=225      ; PERSIST=256/(# of transmitters-1)  — don’t set this to 255 else the two nodes can sync on failure
SLOTTIME=100    ; CMSA interval timer in milliseconds
TXDELAY=0        ; Transmit keyup delay in milliseconds   0 means leave it up to the TNC-PI
TXTAIL=1         ; TX key down, in milliseconds, at packet end
QUALITY=1        ; Quality factor applied to node broadcasts heard on
;                ; this port, unless overridden by a locked route
;                ; entry. Setting to 0 stops node broadcasts
MINQUAL=50       ; Entries in the nodes table with qualities greater or
;                ; equal to MINQUAL will be sent on this port. A value
;                ; of 0 sends everything.
MAXFRAME=1       ; # of frames that can be sent in a single transmission (1 thru 7)
FRACK=4000       ; Level 2 timout in milliseconds -- how long before we retry transmitting to neighbor
RESPTIME=30      ; Level 2 delayed ack timer in milliseconds -- how long after we receive from neighbor before we key up and acknowledge the transmission
RETRIES=20       ; Level 2 maximum retry value
PACLEN=236       ; Default max packet length for this port
UNPROTO=ID       ; BT=EXT broadcast addrs format: DEST[,digi1[,digi2]]
;                ; BCALL=KK4CFN-8 ; BTEXT call. unstated defaults to APPL1CALL
L3ONLY=0         ; 1=No user downlink connects on this port
DIGIFLAG=0       ; Digipeat: 0=OFF, 1=ALL, 255=UI Only
DIGIPORT=0       ; Port on which to send digi'd frames (0 = same port)
USERS=0          ; Maximum number of L2 sessions, 0 = no limit

Tadd / KA2DEW
Raleigh NC  FM05pv

“Packet networking over ham radio":

“Raleigh-centric ham radio resources page":

On Jul 19, 2018, at 7:26 PM, Jon Greene via Groups.Io <jonarmy1@...> wrote:

Currently our club has a stack of 4 Pi TNC, all 4 Pi TNC are hooked to there specific radio via the DB9 connector and using I2C protical

Were currently running LinBPQ on the Raspberry Pi.

So today took a trip up to the mountain were the setup is located at, so I took all 4 of the stack off and checking each I2C config.

So I would reset the Pi TNC to factory, then after pi has booted up, shut it down, then turned the petitioner so it would not be in the factory reset setting.  So after the Pi would start up I'd do the I2Cdetect -y 1 and of course get the blank response with nothing showing like it should. So then I'd do the pitnc_getparams 0 0 and get the reading of the Pi TNC.  So I'd change the address using pitnc_setparams 0 0 7 6 (of course I have 4 total so I spread the I2C address out)

So then I shutdown, unplug wait a moment then boot back up, and then see the Pi TNC at address 6.  Then I would change the TXDelay from the default to some where around 75, this is were it got a little confusing.

After I would change the TXDelay sometimes it would change right away, sometimes it would show TXDelay at like 150 or somewhere in that nature, at some times I would get the bottom were there would be around 14 items at the bottom ex: 8 1 4b 40 a 0 0 0 6 1d 13 c0 sum 0 

Sometimes I would have a total of 3 lines and at the end would be sum 0

Then also with changing the TXDelay, at times I had to do the pitnc_setparams command like 3 times before it responded back with the value I told it.

What could be causing the change in parameters not adjusting right away or the total of 3 lines ending with sum 0

I know when I've restarted sometimes even after knowing the TXDelay was set to around 75 or so, and then when I rebooted the value changed.  Right now I don't have the pi reboot cause I don't want to loose these values, and I've told my other sysop for our packet group not to reboot the pi.


Join to automatically receive all group messages.