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.
