Hi Kiste, Rob,
Thank you for your time.
My comms rig is based on a TTL-232R-5V-AI USB Cable.
My PIC Code:
Setup Segment Code;
-- PPS Setup
include pps
pps_control_lock(FALSE) -- unlock PPS module
RA0PPS = PPS_TX -- pin_A0 is TX
--RXPPS = PPS_RA1 -- RX is on pin_A1
pps_control_lock(TRUE) -- lock PPS module
--
--
--
-- ok, now setup serial
-- Transmission parameters are 8 databits, 1 stopbit, no parity, no
handshake.
alias pin_TX is pin_A0
alias pin_RX is pin_A1
alias pin_TX_direction is pin_A0_direction
alias pin_RX_direction is pin_A1_direction
pin_RX_direction = INPUT
pin_TX_direction = OUTPUT
const serial_hw_baudrate = 38_400
include serial_hardware
serial_hw_init()
--BAUDCON_SCKP=1
RunTime Code;
TransmitWordDataHW(mVal)
TransmitTwoByteDataHW(0xEF, 0x2A + byte(RlyCtl))
...and;
Procedure TransmitWordDataHW(word in Data) is
if defined(serial_hw_write) then
var byte dx[2] at Data
serial_hw_write(dx[1])
delay_10us(1)
serial_hw_write(dx[0])
delay_1ms(5)
end if
End procedure
--
Procedure TransmitTwoByteDataHW(byte in Data1, byte in Data2) is
if defined(serial_hw_write) then
serial_hw_write(Data1)
delay_10us(1)
serial_hw_write(Data2)
delay_1ms(5)
end if
End procedure
Now, VB side;
' setup the default comm port settings
MSComm1.CommPort = Val(Me.Label7.Caption)
MSComm1.RThreshold = 1 ' use 'on comm' event processing
MSComm1.Settings = "57600,n,8,1" ' baud, parity, data bits, stop
bits
'MSComm1.Settings = "38400,n,8,1"
MSComm1.SThreshold = 1 ' allows us to track Tx LED
MSComm1.InputMode = comInputModeBinary ' binary mode, you can also use
' comInputModeText for text
only use
' open the port
MSComm1.PortOpen = True
Maybe am seeing it wrong, but it all seems ok...
And as said, it works good enough using serial_software
Any ideas?
Can also post PIC diagram if needed...
Thank you for all your efforts.
Cheers,
Filipe Santos.
On Tuesday, May 17, 2022 at 5:42:26 PM UTC+1 [email protected] wrote:
> Hi Filip,
>
> This certainly looks like a timing issue especially if you need two
> different baudrates to get it working which is suprising to see that it
> does work.
>
> The serial software library is not so strickt if you look at timing.
> Serial hardware samples the incoming signal and my be more strickt.
>
> As already requested you should send a schematic diagram of your hardware.
> What serial hardware is used on the PC?
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens flyway38 <
> [email protected]>
> *Verzonden:* dinsdag 17 mei 2022 12:48
>
> *Aan:* jallib <[email protected]>
> *Onderwerp:* Re: [jallib] Help about serial_hardware library for the
> 16F18313
> Hi Vasile,
>
> Thanks for the inputs here.
> In fact, theres a problem about the baud rate, but this problem lets
> project work ok using serial_software; PIC is set for 38400 and PC port
> need to be set for 57600. Don't know why, but this is the way it's working
> for several weeks of developing...
> Using serial_hardware lib, not even playing around the baud rate
> divergences makes it work correctly. No correct data arriving to PC or to
> PIC...
> Big puzzle here :D
> Thanks anyways.
>
> Cheers,
> Filipe Santos.
>
> On Tuesday, May 17, 2022 at 5:25:09 AM UTC+1 vasile wrote:
>
> Double check if you have correct settings, baud speed, bit number, parity
> and stop bit. Set something like 9600, 8, N, 1 for the beginning.
> Then check that your terminal is set to display the same thing as you send
> ( if you send hex don't expect that the terminal set for ASCII will display
> correct your data)...
> Last, the problem might be on the computer side as well, not necessarily
> on the PIC...
>
> On Mon, May 16, 2022 at 9:27 PM flyway38 <[email protected]> wrote:
>
> Hi again,
>
> Correction to my last post.
> All working good using serial_software, with invert bit to false.
> But, still Frame or Break issues in communication using serial_hardware...
>
> Have done this Kiste test;
> forever loop
> serial_hw_data=0x22
> serial_hw_data=0x22
> delay_1s(1)
> end loop
>
> and here's the results;
> d7 00 ×.
> d5 00 Õ.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d5 00 Õ.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d7 00 ×.
> d5 00 Õ.
> d7 00 ×.
> d7 00 ×.
> d5 00 Õ.
> d7 00 ×.
> d5 00 Õ.
> d5 00 Õ.
> d7 00 ×.
> d7 00 ×.
>
> Any ideas?
> Thank you very much.
>
> Cheers,
> Filipe Santos
> On Monday, May 16, 2022 at 7:22:48 PM UTC+1 flyway38 wrote:
>
> Hey all,
>
> Miracles do happen.
> Maybe I have an easier way.
> Am using and FTDI cable (USB - RS232/5V) and it has a configurable EEprom.
> This configuration includes inversion of all RS232 signals. Have inverted
> RX and TX and this way am using now serial_software with that inversion bit
> to false.
> Computer receives good data, but it seems RX on PIC side shouldn't be
> inverted... not receiveing good data from computer.
> Can anyone confirm this? TX should be the only one to be inverted?
> Thank you very much.
>
> Kind regrads,
> Filipe Santos.
>
> On Monday, May 16, 2022 at 6:33:38 PM UTC+1 flyway38 wrote:
>
> Hi Rob,
>
> Yes, You're right.
> And yes, will change my design for that hardware comm line inversion.
> Then will back here for results or new issues :D
> Thank you very much for all help.
> Cheers.
>
> Kind regards,
> Filipe Santos.
>
> On Monday, May 16, 2022 at 11:41:31 AM UTC+1 [email protected] wrote:
>
> Hi Filip,
>
> If I understand you right you use inverted serial data. In the serial
> software library everything - including the startbit - is inverted if you
> select the inverted mode. In hardware only the data can be inverted but not
> the startbit.
>
> Is it not possible to add an inverter to your board so that the data is
> not inverted and so you can use serial hardware? You could make an inverter
> with one transistor and 2 resistors.
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens flyway38 <
> [email protected]>
> *Verzonden:* zondag 15 mei 2022 21:20
> *Aan:* jallib <[email protected]>
>
> *Onderwerp:* Re: [jallib] Help about serial_hardware library for the
> 16F18313
> Hey all,
>
> Thank you very much to all.
> Yes, tried timeout option, but I loose alot of received data.
> I think that , for now (8 pin PIC), sending to pic dummy data to unlock
> that loop is my best option.
> This way works better than timeout solution under serial_software lib
> usage.
> Unless some miraculous idea comes along.. :D
>
> Anyways, later on, will redesign this project for a bigger board and use a
> bigger PIC.
> Thank you to all once again.
>
> Kind regards,
> Filipe Santos.
>
> On Sunday, May 15, 2022 at 4:44:36 PM UTC+1 [email protected] wrote:
>
> Hi Kiste,
>
> I fully agree with you. Not worth to add a timeout.
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* 'Oliver Seitz' via jallib <[email protected]>
> *Verzonden:* zondag 15 mei 2022 17:33
>
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* Re: [jallib] Help about serial_hardware library for the
> 16F18313
> Hi Rob,
>
> the most critical thing when receiving asynchronous data, is to precisely
> catch the starting edge of the start bit, as all the timing in the
> following byte depends on it.
>
> while serial_sw_rx_pin loop
> end loop
>
> This is in fact only two machine instructions, and therefore reacts within
> 2Tcy or 2µs at 4MHz.
>
> I did not count the machine instructions for subtracting a dword, but I
> think it must be more than 12 instructions, and another 12 for comparing to
> 0. Plus the 1µs delay, plus the "&"... Will take at least 30µs at 4MHz. If
> that is more than half a bit, data corruption is more than likely.
> 1/60µs=16666 baud is the speed beyond that a 4MHz controller will certainly
> not be able to follow anymore.
>
> If the transmission starts right after the timeout is over, depending on
> the main program, corrupt data will be received (or a byte is completely
> lost).
>
> Serial_software is a poor thing on the receiving side anyway. If you see
> it as an improvement, go ahead. I would under all circumstances avoid using
> serial_software for receiving, even more so with that timeout.
>
> Greets,
> Kiste
>
> Am Sonntag, 15. Mai 2022, 16:57:09 MESZ hat Rob CJ <[email protected]>
> Folgendes geschrieben:
>
>
> Hi Kiste, Filip,
>
> An option would be to extend the serial_software.jal library with a
> maximum wait time for reading and when a timeout occurs return a '0' as
> data.
>
> So something like.
> -- See if a timeout is defined to prevent an endless wait
> if defined(SERIAL_SOFTWARE_READ_TIMEOUT) then
> var dword _serial_timeout = SERIAL_SOFTWARE_READ_TIMEOUT
> -- wait for startbit with timeout
> while serial_sw_rx_pin & (_serial_timeout > 0) loop
> _serial_timeout = _serial_timeout - 1
> _usec_delay(1)
> end loop
> else
> -- wait for startbit without a timeout
> while serial_sw_rx_pin loop end loop
> end if
>
> -- When a timeout is defined and a timeout occcured return 0 as data.
> if defined(SERIAL_SOFTWARE_READ_TIMEOUT) then
> if (_serial_timeout == 0) then
> data = 0
> end if
> end if
>
> Would that work?
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* 'Oliver Seitz' via jallib <[email protected]>
> *Verzonden:* zondag 15 mei 2022 15:46
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* Re: [jallib] Help about serial_hardware library for the
> 16F18313
>
> Hi!
>
> Well... 8 pin is a problem... I only have solutions which aren't that
> elegant...
>
>
> - use a different USB UART, which uses the idle high mode (which in fact
> is standard on 3.3 and 5 volt levels)
> - if you have an I/O pin (other than RA4) to spare, use the comparator or
> a CLC to invert the signal, and connect the output and RX to that same pin
> via PPS
> - use external circuitry to invert the signal, like a MAX232, which is
> inverting since the 1970s and therefore in fact the reason for all the
> confusion ;-)
> - write a new library, which receives by timers and pin-change interrupts
>
> Greets,
> Kiste
>
> Am Sonntag, 15. Mai 2022, 14:56:49 MESZ hat flyway38 <[email protected]>
> Folgendes geschrieben:
>
>
> Hi Kiste,
>
> Understad your points.
> The main issue am trying to solve while using serial_software (wich makes
> my project runs good enough) is that loop while trying to receive data;
> "while !serial_sw_rx_pin loop".
> Because of this loop have to constantly send dummy data to allow PIC out
> of the loop.
> All other code runs fairly ok (somewhat sluggish, but good enough for the
> needs).
> Checked PIC18F14K2, the problem is I need to stick to 8pin THT PIC right
> now...
> On Sunday, May 15, 2022 at 12:42:01 PM UTC+1 Kiste wrote:
>
> Hi Filipe,
>
> that's an important information: seral_sw_invert defaults to "true". If
> you had to set it, you have set it to "false". That means, the line you are
> driving is in "idle low" mode. That mode is not supported by
> serial_hardware, as it is not supported by the classical USART hardware in
> PIC controllers.
>
> You can not cure that problem by sendig serial_hw_data=!value , as that
> does not alter the polarity of start- and stopbits.
>
> With the delay of 300µs between bytes, you do not cure the framing error.
> By doing so, you mislead the receiver to recognise data bits as framing
> bits, so it's one error masking the other error.
>
> If you can use another PIC, like PIC18F14K22, the hardware can be set to
> "idle low" mode for sending and receiving, your 16f18313 can only use the
> transmission side in that mode. So, to make the receiving side work, you
> would have to use additional hardware (or peripherals like CLC or
> comparators) to invert incoming data.
>
> Greets,
> Kiste
>
> Am Sonntag, 15. Mai 2022, 13:06:54 MESZ hat flyway38 <[email protected]>
> Folgendes geschrieben:
>
>
> Hi Kiste,
>
> Thak you very much for your input.
> Will test your code to check and answer you.
> Anyways, right now I can avoid the Framming Error but still receiving
> incorrect data while using serial_hardware library.
>
> About framming Error, the problem was due to the way I sent data to
> transmit reg.
> I was sending two bytes with no delay in between (it works good like this
> using serial_software lib).
> But if I use a delay of about 300us between the two bytes sent, Frame
> Error disppears, but as said above, received data by computer is incorrect.
> Less than that delay, I get Frame Error.
>
> Can answer your question about "const bit serial_sw_invert". * Yes*,
> needed to set this var using serial_software.
> Will back here with answer for your second quest.
> Thank you
>
> Cheers,
> Filipe Santos.
> On Sunday, May 15, 2022 at 10:48:19 AM UTC+1 Kiste wrote:
>
> That data is a bit complex for easy analysis, though I see that you've got
> a repeating value every five bytes in all of the samples. The baud rate
> therefore should not be the problem.
>
> If you want to rely on my guess, insert after "seral_hw_init()"
>
> BAUDCON1_SCKP=1
> If this helps for transmission, you can't use the USART directly for
> receiving, as it has no inversion option for RX. In that case, you can use
> a CLC or a comparator as inverter.
>
>
> If you want to track down the error and learn how to do that, please
> answer my questions:
>
> Have you set "const bit serial_sw_invert" with serial software?
>
> What is the result if you just transmit a single character with pauses?
>
> forever loop
> serial_hw_data="@"
> delay_1s(1)
> end loop
>
>
> Greets,
> Kiste
>
> Am Sonntag, 15. Mai 2022, 11:11:09 MESZ hat flyway38 <[email protected]>
> Folgendes geschrieben:
>
>
> Hello Kiste,
>
> I use Termite to check what flows in my comm line.
> Here's what I see and makes my project work good enough, using
> serial_software (small extract):
>
> 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï
> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ..
> ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ
> 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï
> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ..
> ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ
> 09 00 ee ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..îï*ñ..íï*ñ..íï
> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ..
> ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 íï*ñ..íï*ñ..íï*ñ
> 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï
> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ..
> ed ef 2a f1 09 00 ee ef 2a f1 09 00 ee ef 2a f1 íï*ñ..îï*ñ..îï*ñ
> 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 ed ef ..íï*ñ..íï*ñ..íï
> 2a f1 09 00 ed ef 2a f1 09 00 ed ef 2a f1 09 00 *ñ..íï*ñ..íï*ñ..
>
> Now here's what I see using serial_hardware:
>
> 9a f1 81 80 f5 ef 92 f1 81 80 fd ef 9a f1 81 80 šñ €õï’ñ €ýïšñ €
> f5 ef 9a f1 81 80 f6 ef 9a f1 89 80 fd ef 9a f1 õïšñ €öïšñ‰€ýïšñ
> 89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 f5 ef ‰€þïšñ‰€ýïšñ‰€õï
> 92 f1 81 80 f5 ef 9a f1 81 80 f5 ef 92 f1 89 80 ’ñ €õïšñ €õï’ñ‰€
> f5 ef 9a f1 81 80 f5 ef 9a f1 81 80 fd ef 9a f1 õïšñ €õïšñ €ýïšñ
> 89 80 fe ef 9a f1 89 80 fd ef 9a f1 89 80 fd ef ‰€þïšñ‰€ýïšñ‰€ýï
> 9a f1 89 80 f5 ef 92 f1 81 80 fd ef 9a f1 89 80 šñ‰€õï’ñ €ýïšñ‰€
> fd ef 9a f1 81 80 fd ef 92 f1 89 80 fe ef 9a f1 ýïšñ €ýï’ñ‰€þïšñ
> 81 80 fd ef 9a f1 89 80 f5 ef 9a f1 81 80 fd ef €ýïšñ‰€õïšñ €ýï
> 9a f1 81 80 fe ef 9a f1 81 80 f5 ef 9a f1 89 80 šñ €þïšñ €õïšñ‰€
> f5 ef 9a f1 81 80 ed ef 9a f1 81 80 f5 ef 9a f1 õïšñ €íïšñ €õïšñ
> 89 80 fd ef 9a f1 89 80 f6 ef 92 f1 89 80 fe ef ‰€ýïšñ‰€öï’ñ‰€þï
> 92 f1 89 80 fd ef 92 f1 81 80 fe ef 92 f1 89 80 ’ñ‰€ýï’ñ €þï’ñ‰€
> f5 ef 9a f1 81 80 fe ef 92 f1 89 80 fd ef 9a f1 õïšñ €þï’ñ‰€ýïšñ
> 81 80 fd ef 8a f1 89 80 fd ef 92 f1 81 80 fd ef €ýïŠñ‰€ýï’ñ €ýï
> 92 f1 81 80 fd ef 9a f1 81 80 ed ef 92 f1 89 80 ’ñ €ýïšñ €íï’ñ‰€
>
> Finally, here's what I see using serial_hardware, inverted data in
> serial_hw_write function ("TXREG = !data"):
>
> 82 90 e5 8e fe ff 82 90 e5 8e f6 ff 8a 90 ed 8e ‚ åŽþÿ‚ åŽöÿŠ íŽ
> fe ff 8a 90 ed 8e fe ff 8a 90 e5 8e fe ff 89 90 þÿŠ íŽþÿŠ åŽþÿ‰
> e5 8e fe ff 82 90 e5 8e f6 ff 81 90 ed 8e f6 ff åŽþÿ‚ åŽöÿ íŽöÿ
> 82 90 ed 8e f6 ff 8a 90 e5 8e f6 ff 82 90 ed 8e ‚ íŽöÿŠ åŽöÿ‚ íŽ
> f6 ff 8a 90 ed 8e fe ff 82 90 e5 8e f6 ff 81 90 öÿŠ íŽþÿ‚ åŽöÿ
> ed 8e f6 ff 82 90 e5 8e f6 ff 82 90 e5 8e fe ff íŽöÿ‚ åŽöÿ‚ åŽþÿ
> 8a 90 e5 8e f6 ff 8a 90 e5 8e f6 ff 82 90 ed 8e Š åŽöÿŠ åŽöÿ‚ íŽ
> f6 ff 82 90 e5 8e fe ff 81 90 e5 8e fe ff 82 90 öÿ‚ åŽþÿ åŽþÿ‚
> ed 8e fe ff 82 90 ed 8e fe ff 8a 90 ed 8e fe ff íŽþÿ‚ íŽþÿŠ íŽþÿ
> 82 90 e5 8e fe ff 82 90 ed 8e fe ff 82 90 e5 8e ‚ åŽþÿ‚ íŽþÿ‚ åŽ
> fe ff 8a 90 e5 8e f6 ff 82 90 ed 8e fe ff 82 90 þÿŠ åŽöÿ‚ íŽþÿ‚
> e5 8e fe ff 82 90 e5 8e fe ff 82 90 e5 8e f6 ff åŽþÿ‚ åŽþÿ‚ åŽöÿ
> 82 90 e5 8e f6 ff 81 90 ed 8e f6 ff 8a 90 ed 8e ‚ åŽöÿ íŽöÿŠ íŽ
> f6 ff 82 90 e5 8e f6 ff 8a 90 e5 8e f6 ff 89 90 öÿ‚ åŽöÿŠ åŽöÿ‰
> ed 8e f6 ff 8a 90 e5 8e fe ff 82 90 ed 8e fe ff íŽöÿŠ åŽþÿ‚ íŽþÿ
> 82 90 ed 8e f6 ff 82 90 e5 8e f6 ff 82 90 e5 8e ‚ íŽöÿ‚ åŽöÿ‚ åŽ
>
> It seems serial_hardware is not transmitting same data.
> Any help would be great.
> Thank you.
>
> Cheers,
> Filipe Santos
>
> On Sunday, May 15, 2022 at 6:57:39 AM UTC+1 Kiste wrote:
>
> Hi Filipe,
>
> If serial_software works with "const bit serial_sw_invert = true", then
> serial_hardware should also work. serial_software supports the non-inverted
> mode, the uart hardware in newer PICs also supports the non-inverted mode,
> but the serial_hardware library does not yet support that mode natively.
>
> Have you tried single chars with time in between?
>
> forever loop
> serial_hw_data="@"
> delay_1s(1)
> end loop
>
> This loop transmits a start bit and a single set data bit every second.
> From the results you're seeing on the PC, the error might be narrowed down.
>
> Greets,
> Kiste
>
>
> Am Samstag, 14. Mai 2022, 22:58:28 MESZ hat flyway38 <[email protected]>
> Folgendes geschrieben:
>
>
> Hi to all,
>
> Have been using serial_software library with enough success until now.
> Am coding for use a TTL-232R-5V-AI USB Cable to connect to computer.
> Using serial_software library with invert bit activated, am getting good
> results.
> It all works good enough sending data to computer
> The problem with this library is while receiving data from computer. As
> soon as this funcion is activated in PIC code, the library locks in a loop
> waiting for data.
> So, started to migrate my code for use with serial_hardware library
> instead, to avoid this lock.
> But now I get Frame Error from COMM PORT with not usefull data, all the
> time. Even if I invert data received. Have also tried different baud rates,
> etc...
> Can anyone help about this issue?
> Thank you very much.
>
> Kind regards,
> Filipe Santos.
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/ac896057-cc8b-40e2-9e84-5cc7d7843640n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/ac896057-cc8b-40e2-9e84-5cc7d7843640n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/jallib/1c5acd16-71a0-4b4f-b5a8-f156ebc81377n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/1c5acd16-71a0-4b4f-b5a8-f156ebc81377n%40googlegroups.com?utm_medium=email&utm_source=footer>
>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/jallib/2841ae74-69b7-47ee-be97-6bee2a92cdb9n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/2841ae74-69b7-47ee-be97-6bee2a92cdb9n%40googlegroups.com?utm_medium=email&utm_source=footer>
>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/jallib/7d84e3e6-3865-4d5d-9c1a-f8d125e72413n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/7d84e3e6-3865-4d5d-9c1a-f8d125e72413n%40googlegroups.com?utm_medium=email&utm_source=footer>
>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/1114301196.1951990.1652622400015%40mail.yahoo.com
>
> <https://groups.google.com/d/msgid/jallib/1114301196.1951990.1652622400015%40mail.yahoo.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/GVXP195MB1637F8C203E2069FC8861EC5E6CC9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
>
> <https://groups.google.com/d/msgid/jallib/GVXP195MB1637F8C203E2069FC8861EC5E6CC9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/1514115999.1967130.1652628794740%40mail.yahoo.com
>
> <https://groups.google.com/d/msgid/jallib/1514115999.1967130.1652628794740%40mail.yahoo.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/e2ba34a7-50da-42ab-b20c-4c861f08a423n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/e2ba34a7-50da-42ab-b20c-4c861f08a423n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/e1466126-db21-4b80-a992-bd31734a3042n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/e1466126-db21-4b80-a992-bd31734a3042n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/25af67ac-257b-4160-8f8d-9a62a0b2d512n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/25af67ac-257b-4160-8f8d-9a62a0b2d512n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/dff6c05e-5fe6-4cd1-984c-accec5baf8c0n%40googlegroups.com.
