Loading ...
Sorry, an error occurred while loading the content.

Victory! - was Re:almost there!

Expand Messages
  • MIchael Melnik Sr.
    ... Thats Great Joost, most, probably would have given up by now, My only comment would be serial Port Speed of 1200 Baud is Very Slow, but if you feel
    Message 1 of 45 , Dec 5, 2006
    • 0 Attachment
      --- In BPQ32@yahoogroups.com, zs5s@... wrote:
      >
      Thats Great Joost, most, probably would have given up by now, My only
      comment would be serial Port Speed of 1200 Baud is Very Slow, but
      if you feel confortable with it thats fine, i use 9600 on my two
      KPC3's and 19200 on the 9612, i am sure we are all happy to be of
      help to you.....73-Mike/N9PMO
      >
      > Hello All,
      >
      > The BPQ32/FBB32 combo is on the air.
      >
      > I got the two 'talking' to each other some days ago
      > but, as reported to the group, could not receive
      > or transmit.
      > This was a bit of a blow as I expected it to be
      > the easy part.
      > In case you are interested in the solution:
      >
      > I activated WinPack (an excellent program), on the
      > same com-port, same PK232 and same VHF radio.
      > It showed strings of one character (C+,) which is
      > normally a sign of the wrong Baud rate.
      > WinPack's default was 9600. After lowering it to
      > 1200 monitoring worked beautifully.
      > Back to BPQcfg.txt, port section, changed SPEED=9600
      > to =1200 and BPQTerminal.exe and FBB's monitor function
      > did what they were expected to do.
      >
      > It turned out WinPack was transmitting and I could
      > connect to another BBS.
      > In my opinion, this limited the problem to the BPQ
      > configuration.
      > I compared my parameters to those found in
      > .../BPQ32/Configurations/Large_without_AGWPE by N5IN.
      > There appeared to be more params than there used to
      > be and I added those to the config file.
      > Also I made quite a number of changes.
      > Most noticable, I changed
      > TXDELAY 500
      > into
      > TXDELAY=400.
      > Note the missing '=' was added in again.
      > Whatever did the trick, my FBB is up and running now.
      >
      > I am specially thankfull to John, G8BPQ and Mike, N9PMO,
      > for their continued assistance but also to Harold, KB7RSI,
      > Tony, VK5AH and Art, N9ZZK for getting me on the track.
      >
      > A few months ago I knew a lot of hams who couldn't get
      > BPQ32 and FBB32 to work.
      > Hopefully, in future, I can be of assistance to them.
      >
      > 73,
      >
      > Joost, ZS5S
      >
      >
      >
      >
      >
      >
      >
      > ------------------------------------------------------------------
      >
      > For Homepage double-click: http://zs5s.net
      >
    • John Wiseman
      With PROTOCOL=KISS, the FULLDUP parameter is passed to the TNC, and all the KISS implementations I know of will obey the param (ie not transmit if carrier is
      Message 45 of 45 , Apr 7, 2008
      • 0 Attachment
        With PROTOCOL=KISS, the FULLDUP parameter is passed to the TNC, and all the KISS implementations I know of will obey the param (ie not transmit if carrier is present and FULLDUP=0). Also all that I know will operate true full duplex (simultaneous transmit and receive) if the frequencies are far enough apart (probably crossband, but with good enough cavity filters could be in same band), No handshaking signals are used, so a 3 wire cable is fine.
         
        With PROTCOL=NETROM, FULLDUP controls the link between the PC and TNC(s). With BPQ32 it has to be set to 1, and only supports 1 TNC, but with the old DOS BPQCODE you could set FULLDUP=0, and connect a stack of NET/ROM TNC's via a diode matrix. In this case the RTS and CTS lines control the matrix.
         
        73,
        John G8BPQ
         
         
        -----Original Message-----
        From: BPQ32@yahoogroups.com [mailto:BPQ32@yahoogroups.com]On Behalf Of Ron Stordahl
        Sent: 07 April 2008 15:29
        To: BPQ32@yahoogroups.com
        Subject: Re: [BPQ32] Full DCD signal but will still transmit

        I am quite interested in this issue.  I have always used the JKISS or BPQKISS ROM, with minimal wiring (RX,TX and GND) and FULLDUP=0, and have never noticed the TNC (MFJ1270C's) stomp on a signal being received (with the DCD led illuminated) .

        This does bring up the possibility that if the RX and TX frequencies are far removed, it may be possible to operate full duplex.  I had thought the hardware prevented this, but perhaps not?

        With PROTOCOL=NETROM is is necessary that FULLDUP=1 for the interface to function.  Might it then transmit with DCD on and thus stomp on the received packet?

        While I have always used the minimal cabling, might full cabling be required in some cases?

        http://groups. yahoo.com/ group/BPQ32/ files/BPQ32_ RS232_Cabling/

        Ron, N5IN



        ----- Original Message ----
        From: John Wiseman <john.wiseman@ ntlworld. com>
        To: BPQ32@yahoogroups. com
        Sent: Monday, April 7, 2008 2:56:06 AM
        Subject: RE: [BPQ32] Full DCD signal but will still transmit

        Dave,
         
        Setting FULLDUP=0 in the port definition should stop it, although this relies on the TNC obeying the relevant KISS command.
         
        73,
        John
         
        -----Original Message-----
        From: BPQ32@yahoogroups. com [mailto:BPQ32@ yahoogroups. com]On Behalf Of David Calder
        Sent: 06 April 2008 18:19
        To: BPQ32@yahoogroups. com
        Subject: [BPQ32] Full DCD signal but will still transmit

         
        My BPQ ports will transmit on top of someone even if the TNC shows it having
        a full good DCD. IT will just tromp on them anyway.
         
        In the old BPQ (which is on my dead machine) I seem to remember a port
        command to stop that. What was it?
         
        Thanks,
        73 Dave
        n4zkf
         

      Your message has been successfully submitted and would be delivered to recipients shortly.