Hi Rob,
Sorry for the misunderstandings I saw below. Nobody blames you for
anything, on the contrary, congratulates you!
 I've noticed there is no difference with and without the if - end if block
used to test the PLL ready after normal power up.
However,  I have not yet tested what's happening when dual speed oscillator
mode is used  or when the PIC wakes from sleep, and here you may have right.
I was also not able to set up yet a valid USB communication with HFINTOSC,
PLL and ACT. So far, my experience with USB is quite ugly.
thx for support!


On Mon, Mar 1, 2021 at 9:12 PM Rob CJ <[email protected]> wrote:

> Hi Vasile,
>
> I do not agree with what you are saying here. If a library has a potential
> bug it should be fixed (like the PLL addition).
>
> The datasheet of the 16F1455 clearly states:
>
> Nice that you can measure this on a scope but I do not know what happens
> if you would turn the PIC to sleep and wakeup from that if and 'hope' your
> PLL is up and running when continuing from the last statement.
>
> Note that when I make changes I test it with different sample files, not
> only the one I am working on. I also update the compiler version in the JAL
> file to the version with which I compiled it (I may have missed this for
> some USB driver files but fixed that this weekend).
>
> FYI. I am OK if you report bugs in libraries but I do not find these kind
> of e-mails very motivating to continue to improve JAL libraries or add  new
> ones.
>
> Kind regards,
>
> Rob
>
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens vsurducan
> <[email protected]>
> *Verzonden:* maandag 1 maart 2021 07:03
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* Re: [jallib] WIN32CDCDrivers?
>
> Rob, on PIC18F2550 works for me too, not too reliable, but works.
> It does not work on PIC18F25k50.
>
> You should know also there are minor differences between the
> "USB_enable_module" procedure from usb_drv.jal library contained in
> jalpacks 1.5.0 and 1.6.0.
> Perhaps there are also other modifications.
>
> For PIC18F25k50 the registers involved in PLL should be:
> alias OSCON_SPLLEN is OSCCON2_PLLEN        -- for PIC18F25K50
> alias OSCSTAT_PLLRDY is OSCCON2_PLLRDY
> However the time required for PLL to stabilize is so short (I've measured
> with a scope) that the modification from jalpack 1.6.0 is useless. I think
> that a library which worked at a moment with a compiler should be preserved
> "as is" with no modifications. Also the compiler version should be clearly
> specified manually in all libraries which worked and avoid automatic
> changes at each upgrade of the pack.... There is no time to check seriously
> all the libraries at each new jalpack release.
>
>
> -- jalpack
> 1.5.0--------------------------------------------------------------------------------------
> -- Procedure to turn on the USB device
> --
> --------------------------------------------------------------------------------------
> procedure usb_enable_module() is
> pragma inline
> UIR = 0
> UCON = 0x00
>
> -- enable USB serial interface engine (SIE)
> UCON_USBEN = high
> usb_state = USB_STATE_DEFAULT
> end procedure
> --
> -----------------------------------------------------------------------------------
>
> --
> jalpack1.6.0-------------------------------------------------------------------------------------
> -- Procedure to turn on the USB device
> --
> --------------------------------------------------------------------------------------
> procedure usb_enable_module() is
> pragma inline
> UIR = 0      -- Clear all interrupt status flags
> UCON = 0x00
>
> -- If we use the PLL we have to wait until it is ready before enabling
> -- the USB serial interface (see PIC data sheet of 16F1455 section 26.2).
> -- Only valid for devices that have a PLL ready indication.
> if defined ( OSCCON_SPLLEN ) then
>     if defined ( OSCSTAT_PLLRDY ) then
>    if OSCCON_SPLLEN then
>      while !OSCSTAT_PLLRDY loop  -- Wait for PLL to be ready.
>         end loop
>       end if
>     end if
>    end if
>
> -- enable USB serial interface engine (SIE)
> UCON_USBEN = high
> usb_state = USB_STATE_DEFAULT
> end procedure
> -- -----------------------------------------------------------------------
>
> On Sun, Feb 28, 2021 at 7:56 PM Rob CJ <[email protected]> wrote:
>
> Hi Vsurducan,
>
> I did a test on the PIC18F2550 using the standard JAL serial sample
> library program. That program uses these pragma's:
>
> pragma target  clock 20_000_000
> pragma target  OSC        hs
> pragma target  LVP enabled                   -- allow LVP
> pragma target  WDT CONTROL                   -- WDT software controlled
> WDTCON_SWDTEN = OFF                          -- disable WDT
>
> It did not work, since my computer never recognized the PIC as COM port so
> I changed it to this:
>
> pragma target clock 48_000_000      -- oscillator frequency
> pragma target OSC      HS_PLL                    -- HS osc + PLL
> pragma target PLLDIV   P5                        -- 20 MHz
> pragma target CPUDIV   P1                        -- Fosc divisor
> pragma target USBDIV   P2                        -- USB clock selection
> pragma target WDT      CONTROL                   -- watchdog
> pragma target XINST    DISABLED                  -- do not use extended
> instructionset
> pragma target DEBUG    DISABLED                  -- no debugging
> pragma target BROWNOUT DISABLED                  -- no brownout reset
> pragma target FCMEN    DISABLED                  -- no clock monitoring
> pragma target IESO     DISABLED                  -- no int/ext osc
> switching
> pragma target VREGEN   ENABLED                   -- voltage regulator used
> pragma target LVP      ENABLED                   -- low voltage programming
> pragma target MCLR     EXTERNAL                  -- external reset
> WDTCON_SWDTEN = OFF                 -- disable WDT
> OSCCON_SCS = 0                      -- select primary oscillator
>
> This worked, my computer recognized the PIC as COM7 on my computer.
>
> I then added a counter in the loop and had sent its value every 50 ms to
> the output. It sometimes stopped after a count of 300 (note that I made the
> 50 ms NOT using usec_delay since then the USB driver would not work). If
> you would enter characters when it stopped it did no longer reply them.
>
> I then tried the same using the interrupt based version that I am
> currently working on (now I could use usec_delay in the main loop). That
> seemed to work better - while typing this the counter is at 17.000 and
> still counting - but also there it happend at least once that it stopped
> but I am not sure if that was because  I was also entering a lot of
> character on the keyboard. This requires some further investigation.
>
> I did not yet try this on another PIC but I will do that later.
>
> I do not  know which pragma's you are using but the pragma's given in the
> standard sample program for the PIC18f2550 do not work.
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens Rob CJ <
> [email protected]>
> *Verzonden:* zondag 28 februari 2021 16:54
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* Re: [jallib] WIN32CDCDrivers?
>
>  Hi Vsurducan,
>
> Ok I will test the sample program on the same PIC you are using to see if
> it is related to the PIC.
>
> Met vriendelijke groet,
> Rob Jansen
> ------------------------------
> *From:* [email protected] <[email protected]> on behalf of
> vsurducan <[email protected]>
> *Sent:* Sunday, February 28, 2021 4:34:47 PM
> *To:* [email protected] <[email protected]>
> *Subject:* Re: [jallib] WIN32CDCDrivers?
>
> Hi Rob, thx,
> Unfortunately you are right, the cleaned library behaves as the old one.
> I have no ADC running yet. :) I'm just trying to send a bunch of chars
> from the PIC to the host in a predictive way with no success.
> USB serial communication runs only if I receive a char and send a data on
> each received char, and even in this situation it freezes after a number of
> chars sent.
>
> PIC18F25k50 runs exactly the same at 5V (3.3V on VUSB), just for the
> record.
>
>
> On Sun, Feb 28, 2021 at 4:30 PM Rob CJ <[email protected]> wrote:
>
> Hi Vsurducan,
>
> The updated USB will not solve your problem, it was only cleaned up but
> not functionally changed.
>
> What might be an issue is the conversion time of the ADC. Your call 
> adc_read(0)
> is a blocking call since it waits until the ADC conversion is complete.
> This may - not sure - be too long for the  usb_serial_flush().
>
> If that is the problem then there are - at least - two options:
> -) Start the AD conversion yourself and check if conversion is still
> ongoing by checking ADCON0_GO. If so skip the reading part until conversion
> is complete and then read the ADC value.
> -) Use an interrupt based version of the USB driver. I re-started working
> on that today and it seems to work for USB serial (tested with a PIC16F1455
> and PIC18F14K50) since then you no longer need the usb_serial_flush()
> because the handling of the USB driver is done in the interrupt routine.
>
> As said I am not yet done with the update of the USB interrrupt based
> driver but as soon as it works I will upload it. For now you could try the
> other option by checking if conversion is ongoing.
>
>
> With the interrupt based USB driver my main usb_serial sample program now
> looks like this:
>
> const USB_INTERRUPT_DRIVEN = TRUE    -- This needs to be set to use the
> interrupt driven mode
>
> forever loop
>
>     -- There is no serial flush anymore 🙂
>
>     -- check if USB device has been configured by the HOST
>    if ( usb_cdc_line_status() !=  0x00 )  then
>       if !has_shown_welcome_msg then
>          has_shown_welcome_msg = true
>          print_string( usb_serial_data, str_welcome )
>       end if
>    else
>       has_shown_welcome_msg = false
>    end if
>
>    -- check for input character
>    if usb_serial_read( ch ) then
>       -- echo input character
>       usb_serial_data = ch
>    end if
>
> end loop
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens vsurducan
> <[email protected]>
> *Verzonden:* zondag 28 februari 2021 10:37
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* Re: [jallib] WIN32CDCDrivers?
>
>
>
> On Sun, Feb 28, 2021 at 10:04 AM Rob CJ <[email protected]> wrote:
>
>  Hi Vsurducan,
>
> To understand this better. The program you mention does not work for that
> PIC running at 3.3 Volt, right? I have 2 questions:
> 1) Have you tried what happens when running it at 5 Volt?
>
>
> No because it has to work on 3.3V. However I will try it to see if it
> makes things different.
>
> 2) What did you do with the 3.3 Volt generated by the PIC for the USB? I
> can imagine that it cannot generate that Voltage if it is powered by 3.3.
> Volt.
>
>
> It's within specifications Rob. 3.3V on VDD, 3.1V on VUSB.  Tio understand
> better, I'm a hardware guy working in electronics from 35years now.
> However, software is still not my favorite thing...
>
>
> For your information. Some years ago I updated the USB driver to make it
> suitable for a PIC16F1455 but due to a compiler bug I had to implement a
> workaround to get that working. This  compiler bug was fixed some time ago
> so I removed all these workarounds and uploaded the 'clean' USB library
> again to GitHub yesterday.
>
>
> Oki, I will test it thank you.
>
>
> Currently  I am looking at making the USB driver operate on an interrupt
> basis as to get rid of the need for flushing it. So if there are any other
> problems with the driver I can have a look but I have to understand your
> application.
>
> I general if you have a problem, try to minimize the code to the
> essentials so that it becomes more easy to analyze the issue.
>
>
> It's the minimum possible: the example "18F4450_usb_serial.jal" has been
> adapted for PIC18F25K50.
> The only thing which works from this example is  the part below:
>
> forever loop
> -- poll the usb ISR function on a regular base, in order to
> -- serve the USB requests
> usb_serial_flush()
>
> -- check for input character
> if usb_serial_read( ch ) then
> -- echo input character
> usb_serial_data = ch
> end if
>
> end loop
>
>
>
>
> Thanks.
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens vsurducan
> <[email protected]>
> *Verzonden:* zondag 28 februari 2021 07:43
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* Re: [jallib] WIN32CDCDrivers?
>
> Hi Rob,
> Nope, with PIC18F25K50 at 3.3V supply nothing workswith usb_serial library
> except the echo part which is useless for me. Anything else is closing the
> USB host port and device is seen as unknown.
>
> About delay, please take a look at one good example of funlw65 (below)
> where it has about 1 second delay by flushing in the meantime. However this
> example is not relevant for using only the usb_serial because it uses the
> bootloader  with different fuses configuration and different location for
> the code which runs.
> On PIC18F2550 at 5V supply and external HOSC, the actual USB library does
> not send data reliably as an FT232 would do, an amount of data from ADC for
> example would be sent to the terminal with variable speed even if the main
> loop has  very simple structure with fixed computing time. Sometimes the
> transmission stops, to resuscitate it,  the port has to be closed and
> opened again on the host side...
> I do not know why this happens, the library is too twisted for my taste so
> perhaps I will modify it if I'll have nerves for that...
>
>
>
> -- Project: ADC read and send on USB CDC
> -- Author: Vasile Guta-Ciucur (funlw65)
> -- License: Code released under New BSD license
> -- For jallib libraries, see de licence inside jal.zip
>
> include freejalduino4 -- FreeJALduino4 pinout layer for the last board
> model
>
> -- include libraries
> include usb_serial
> include print
> include format
> include delay
>
> var dword Value
> var word AD_RESULT
> var word Volts
> -- var byte Millivolts
> const byte str1[] = " Volts\n\r"
>
>
> -- ==================================================
> -- PROGRAM START ------------------------------------
> -- ==================================================
> -- configure pins
> enable_digital_io() -- first, all pins set to digital
>
>
> -- now configure ADC constants
> const bit ADC_HIGH_RESOLUTION = true -- 10bit resolution
> const byte ADC_NVREF = 0 -- no voltage reference
> const byte ADC_NCHANNEL = 1 -- how many ADC channels we are using,
>                             -- always starting the count from A0 (RA0/AN0)
>                             -- This will automatically set A0 as analog
> input
> const word ADC_RSOURCE  = 909 -- impendance (R1*R2/(R1+R2))
> -- then, load the ADC library
> include adc
> -- Initialize ADC
> adc_init()
>
>
> -- initialize the USB serial library
> usb_serial_init()
>
> -- start main loop
> forever loop
>   usb_serial_flush()
>   AD_RESULT = adc_read(0)
>
>   print_word_dec(usb_serial_data, AD_RESULT)
>   usb_serial_data = " "
>
>
>   -- Value = 537 * AD_RESULT
>   Value = dword(537) * AD_RESULT -- one of the operands must be casted
>                                  -- as dword to have a 32bit integer math
>                                  -- because AD_RESULT is word and the other
>                                  -- operand is a generic one.
>
>   Volts = Value / 100
>
>   format_word_dec(usb_serial_data, Volts, 4, 2)
>   print_string(usb_serial_data, str1)
>
>   for 100 loop -- delay 1 second (a little more than)
>     usb_serial_flush()
>     delay_1ms(10)
>   end loop
>
> end loop
> --
> On Sat, Feb 27, 2021 at 9:03 AM Rob CJ <[email protected]> wrote:
>
> Hi Vsurducan,
>
> Did you fix this issue? So far I never had issues with the USB driver but
> I had always used it with a crystal. Why are you using udc_cdc_putc()?
>
> About your other post about the USB driver. I saw that you used a delay of
> 400 ms in your main program. This may not work since the USB driver needs
> to be polled by usb_serial_flush() and this needs to be done quite
> frequently (I thought miliseconds).
>
> I already found this polling a bit anoying myself since it would be nicer
> to have it done on an interrupt basis. Some time ago I started to make it
> interrupt driven but it did not work immediately at that time. Maybe it is
> a good time to pick it up again.
>
> Kind regards,
>
> Rob
>
>
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens vsurducan
> <[email protected]>
> *Verzonden:* woensdag 24 februari 2021 20:33
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* Re: [jallib] WIN32CDCDrivers?
>
> Thank you Matt and Rob,
> I have a non reliable USB communication under both Win10 and Win7 so I'm
> suspecting everything...
> The following sample is based on 18F4550_USB_serial.jal. PIC18F25K50 has
> the same registers as PIC18F2550 except some PLL bits which can be ignored
> with a delay.
> However, USB works only with the echo. Trying to repeatedly send a byte
> from PIC to PC, communication it froze.
>
> include 18f25k50                     -- target PICmicro
> --
> -- This program assumes that a 16 MHz resonator or crystal
> -- is connected to pins OSC1 and OSC2.
> pragma target clock 48_000_000      -- oscillator frequency
> --
>
> pragma target OSC      HSH                       -- crystal or resonator
> pragma target PLLSEL   PLL3X
> pragma target PLLEN    ENABLED                   -- PLL on
> pragma target CPUDIV   P1                        -- Fosc divisor
> pragma target WDT      DISABLED                  -- watchdog
> pragma target XINST    DISABLED                  -- do not use extended
> instructionset
> pragma target DEBUG    DISABLED                  -- no debugging
> pragma target BROWNOUT DISABLED                  -- no brownout reset
> pragma target FCMEN    DISABLED                  -- no clock monitoring
> pragma target IESO     DISABLED                  -- no int/ext osc
> switching
> pragma target LVP      DISABLED                   -- low voltage
> programming
> pragma target MCLR     EXTERNAL                  -- external reset
> --
> -- The configuration bit settings above are only a selection, sufficient
> -- for this program. Other programs may need more or different settings.
> --
> OSCCON_SCS = 0                      -- select primary oscillator
> --
> enable_digital_io()                 -- make all pins digital I/O
> WDTCON_SWDTEN = OFF                     -- disable watchdog
>
> include delay
> include usb_serial
> include print
>
> -- constants
> const  byte str_welcome[] = "JALLIB USB Serial Demo app\n"
>
> -- variables
>
> -- interrupts? No thanks
> INTCON_GIE = false
>
> -- setup the USB serial library
> usb_serial_init()
>
> var bit has_shown_welcome_msg = true
> var byte ch
>
> -- main loop
> forever loop
> -- poll the usb ISR function on a regular base, in order to
> -- serve the USB requests
> usb_serial_flush()
>
>     -- check if USB device has been configured by the HOST
> if ( usb_cdc_line_status() !=  0x00 )  then
> if !has_shown_welcome_msg then
> has_shown_welcome_msg = true
> print_string( usb_serial_data, str_welcome )
> end if
> else
> has_shown_welcome_msg = false
> end if
>
> -- check for input character ; this works
>  if usb_serial_read( ch ) then
> -- echo input character
>     usb_serial_data = ch
>  end if
> ; none of the following works, the USB is frozen...
> ;    usb_cdc_putc ("B")
> ;    format_word_dec(usb_serial_data, 0x3FC , 4, 0)
> ;    print_byte_dec(usb_serial_data, 0x04)
>
>
>
> On Wed, Feb 24, 2021 at 9:02 PM Matt Schinkel <[email protected]>
> wrote:
>
> Hi, it is in jallib under tools/usb
>
> Sent from my Android device.
>
> ------------------------------
> *From:* [email protected] <[email protected]> on behalf of
> Rob CJ <[email protected]>
> *Sent:* Wednesday, February 24, 2021 1:41:57 PM
> *To:* [email protected] <[email protected]>
> *Subject:* Re: [jallib] WIN32CDCDrivers?
>
>  Hi Vsurducan,
>
> I do not know but I think you do not need them. When I updated the serial
> library some time ago I could test it with a JAL sample program. Windows 10
> recognized the usb device without the need for driver.
>
> If you use an older version of Windows I do not know if this is also true.
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens vsurducan
> <[email protected]>
> *Verzonden:* woensdag 24 februari 2021 19:17
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* [jallib] WIN32CDCDrivers?
>
> Hi, where can I find a copy of  the Win32CDCDrivers.zip ?
> The links posted in the usb_serial_demo are broken.
> thanks,
> --
> 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/CAM%2Bj4quYAsdKiqVSCM%2BV6%2BaPFLvyeGj5WWfCgGnETB-e%2BW8wwQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4quYAsdKiqVSCM%2BV6%2BaPFLvyeGj5WWfCgGnETB-e%2BW8wwQ%40mail.gmail.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/AM0PR07MB6241E6D8D505B288C9B322B1E69F9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB6241E6D8D505B288C9B322B1E69F9%40AM0PR07MB6241.eurprd07.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/YQXPR01MB41496334B29E540ECA2A9766DE9F9%40YQXPR01MB4149.CANPRD01.PROD.OUTLOOK.COM
> <https://groups.google.com/d/msgid/jallib/YQXPR01MB41496334B29E540ECA2A9766DE9F9%40YQXPR01MB4149.CANPRD01.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/CAM%2Bj4qtwEeyURARHT7%3Dc2%2BqE-w7AtFX0Hmyg%2ByJAOL7q%3DGCEAQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qtwEeyURARHT7%3Dc2%2BqE-w7AtFX0Hmyg%2ByJAOL7q%3DGCEAQ%40mail.gmail.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/AM0PR07MB6241C7A557FE8743121FB378E69C9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB6241C7A557FE8743121FB378E69C9%40AM0PR07MB6241.eurprd07.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/CAM%2Bj4qvwzWBSCXT1RQEYEucBtW%2BSLYOinp%3DxSt6HZgKTnZ5ECA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvwzWBSCXT1RQEYEucBtW%2BSLYOinp%3DxSt6HZgKTnZ5ECA%40mail.gmail.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/AM0PR07MB6241E61D143816CC5B793407E69B9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB6241E61D143816CC5B793407E69B9%40AM0PR07MB6241.eurprd07.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/CAM%2Bj4qvBKoEeVO7-_tOxhUGFcd9nQ714g1Ufs%3DzS8%2BgmfnTqtg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qvBKoEeVO7-_tOxhUGFcd9nQ714g1Ufs%3DzS8%2BgmfnTqtg%40mail.gmail.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/AM0PR07MB624163DA01D4AE936236F2DDE69B9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB624163DA01D4AE936236F2DDE69B9%40AM0PR07MB6241.eurprd07.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/CAM%2Bj4qt0xk%3DLtekZRyYCjKe-EyjoH2JdiiSoHwf_AXWwC9um-g%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qt0xk%3DLtekZRyYCjKe-EyjoH2JdiiSoHwf_AXWwC9um-g%40mail.gmail.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/AM0PR07MB62415D8E8D60EAC2D98A5C7BE69B9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB62415D8E8D60EAC2D98A5C7BE69B9%40AM0PR07MB6241.eurprd07.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/AM0PR07MB62413D6F8CED238ADA169DB2E69B9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB62413D6F8CED238ADA169DB2E69B9%40AM0PR07MB6241.eurprd07.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/CAM%2Bj4qt7eTMvYkJvKu3V_uJGcerqAEUH_hG57VCtwaV3Ut62SA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qt7eTMvYkJvKu3V_uJGcerqAEUH_hG57VCtwaV3Ut62SA%40mail.gmail.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/AM0PR07MB62416E22E5B9A798F1694C69E69A9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB62416E22E5B9A798F1694C69E69A9%40AM0PR07MB6241.eurprd07.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/CAM%2Bj4quU3ery6Cs%2BJ%3D9x%2Bsz1e1WkBkyXwuFFfS810JyatvP-0g%40mail.gmail.com.

Reply via email to