PIC18F13K50, CDC USB communication and ultra-low power temperature logger


Closed Thread
Results 1 to 28 of 28

Hybrid View

  1. #1
    Join Date
    Dec 2007
    Location
    Paris
    Posts
    101

    Default PIC18F13K50, CDC USB communication and ultra-low power temperature logger

    Dear everyone!

    I am in the process of starting a new project around the 18F13K50, which have to mix ultra-low power and USB communication, a combination that seems to be difficult to mix.

    I had previous success (about 3 years ago) with a couple of very simple project around the 18F2550/4550 and CDC communication profile. But now it seems that there is much more new things added to USB coding, including new USB handling library, and of course new USB pics from microchip too! The PIC18F13K50/14K50 is now becoming an exciting candidate for very small USB projects, and after upgrading MPLAB, purchasing a PicKit 3 and trying to makes everything working back together I can now concentrate on writing code!

    Now onto the project, it is a temperature logger that will sample temperature at a preset interval of time and store it in EEPROM. Content of the EEPROM can then be uploaded to a computer using the CDC USB profile. This is actually very similar in conception to jellish00 ultrasonic logger project that was discussed a bit in this post.

    Temperature logger in standalone mode
    Now the challenge is to run the device out of an ultra-small 25mAh LiPO battery. That is not a whole lot of juice, but using power conservation technique I hope to be able to run it for a long period of time (namely, a few months).

    The hardware that will actually eat power on the device:
    - 3,3V Voltage regulator, TPS72933, quiescent current 500nA.
    - I2C EEPROM, quiescent current about 1ľA, 5mA when writing.
    - I2C Temperature sensor TMP100, quiescent current about 1ľA, 70ľA when sampling.
    - A bicolor LED, for indicating errors (battery low, memory full). This will not be normally used.
    - The PIC, which is going to be the biggest battery drain.

    Here's my idea for power-saving for the PIC. Ideally a timer with the crystal used as a clock source (for accuracy) would be used to define my sampling interval (ideally 1sec, or 5sec). this would send an interrupt to the PIC, getting it out of sleep mode. It would then increment a counter (to get to longer sampling intervals), and when needed, trigger a temp sample on the TMP100 and store it to EEPROM. Then going back to sleep till next timer interrupt.

    The USB charger is also connected to INT0 to send an interrupt when the USB power is connected.

    The battery voltage level is also measured with the PIC ADC, but can be polled with temperature.

    While the timer is ran on the external crystal oscillator, the PIC core may have to be run on the LF internal oscillator (31kHz), providing the lower consumption. The operation in standalone mode is actually not very challenging, what is more is to do it with little power!

    Temperature logger in USB mode
    In USB mode the logger will charge its battery over the USB current. I will have to wake the USB module oscillator, and very likely to change the core frequency to a much faster pace in order to send the data rapidly. The complicated part is all the USB code to handle the CDC communication, and I don't see myself writing that in C or assembler!

    While I understood that the PIC can support all this in hardware, I am not sure about the capability yo implement it all in PicBasic, at least without using ASM calls. DEFINE OSC can only be used once, making a change in OSC frequency difficult for all PAUSE and delays used in the program. DEFINE OSC cannot accommodate for anything lower than 3.58MHz too. Hardware interrupt are not very obvious to handle in PicBasic, though I just found out the library written by Darrel Taylor which looks very promising. I have yet to dig in the details for using it.


    Here is the quick and dirty prototype... at least the hardware works nicely!



    Of course there's extra things too, the LCD is actually quite handy for debuging
    Here it is polling temperature from the TMP100 in "one shot" sample mode, displaying it as the raw 12bit data + converted value (Yes it is hot in Paris tonight!).

    Any consideration on the feasibility of such project with PicBasic?

    I will probably have more question that will arise while advancing in the programming...

    Looking forward to discuss around this!

  2. #2
    Join Date
    Jan 2009
    Location
    Miami, Florida USA
    Posts
    644

    Default

    Quote Originally Posted by aberco View Post
    Here it is polling temperature from the TMP100 in "one shot" sample mode, displaying it as the raw 12bit data + converted value (Yes it is hot in Paris tonight!)
    Ooh, I love your city. I'm turning red now...

    Well, that's a lot of info in one post. I think your project can be done in PBP with no problem. The part that I think is unrealistic is trying to get this device running for a few months with a 25mAh LiPO battery. Let's say that the average comsumed current of your device is 1mA, then with some luck you can run your device for 25 hours. You are taking into consideration only the quiescent currents, but what about the operating currents?

    Is this device going to be connected to the USB port all the time? Can you use a bigger battery?

    Robert
    "No one is completely worthless. They can always serve as a bad example."

    Anonymous

  3. #3
    Join Date
    Dec 2007
    Location
    Paris
    Posts
    101

    Default

    Hi Bob! thanks for your observations!

    Indeed, 1mA is waaaay too much!!!

    I am giving the quiescent current because this is what is consumed most of the time. The component will be turned on when sampling for a couple ms, a couple of time a day.

    Without counting the PIC, I have at most 3ľA of current IDLE, and 5mA at most when writing to EEPROM. To simplify calculation let's say we use the sampling routine for 1 second every hour (that's likely to be longer than needed). So, for hourly consumption that gives: (1*5/3600)+(0.003*3599/3600) = 4,38 ľAh
    That's about 190 days on 20mAh.

    I have already all conservation routines programmed and tested for the peripherals, so I'm confident that these numbers are meaningful. I measured them on my prototype.

    Now comes the PIC! The solution would be to shut off the CPU core between sampling and use interrupt from the timer to wake it up. Peripherals and timers can work on their own, and this would cut down the PIC consumption to a few ľA too.


    Now the device itself will be build inside the body of an USB jumpdrive. It will not be connected to USB when sampling, so there's no available power. The limited amount of space within the jumpdrive body does not allows for much options as well. I have found the smallest LiPO battery, the 25mAh model, that can fit within 1 by 2cm space in the back of the enclosure. They have a 60mAh model too, but it is significantly larger, and I need to keep some space to cram SMD components on the PCB too. So, Is this device going to be connected to the USB port all the time? No, and Can you use a bigger battery? If I really have to that will be the option. However I first need to design the device to be the most power efficient, regardless of available battery capacity.

    I'll go through a step by step testing of these power saving possibilities with PicBasic... hopefully without ASM calls!

  4. #4
    Join Date
    Dec 2007
    Location
    Paris
    Posts
    101

    Default 18F13K50/14K50 clocking

    Trying to get the USB com. working.
    Now there's a little details that I have seen stated but not previously understood:

    The 18F13K50/14K50 requires the use of an external crystal of 12 or 48 Mhz ONLY! The internal clock circuitry is in fact simpler than what the 2550/4550 has, and the only option to feed the USB oscillator is either directly or using a x4 PLL. CPU frequency can then be derived from the PLL using ÷1, 2, 3 or 4.

    No problem for my USB mode, but for my low power mode running at 12Mhz is out of question. That will require the use of the internal RC oscillator, and a loss of timing precision between the temperature samples (which is not overly critical).

    An other solution is to use the second external oscillator and wire a 32,768kHz crystal to it (with a bit more PCB real estate used).

  5. #5
    Join Date
    Jan 2009
    Location
    Miami, Florida USA
    Posts
    644

    Default

    "No one is completely worthless. They can always serve as a bad example."

    Anonymous

  6. #6
    Join Date
    Dec 2007
    Location
    Paris
    Posts
    101

    Default

    Cool! I missed this thread, I'll dissect it carefully, looks pretty much like all I want!

  7. #7
    tron235's Avatar
    tron235 Guest

    Default Re: PIC18F13K50, CDC USB communication and ultra-low power temperature logger

    Anyone know if this is still an active item PIC18F13K50T-I/SO
    Last edited by tron235; - 4th November 2011 at 18:31.

  8. #8
    Join Date
    May 2007
    Posts
    604

    Default Re: PIC18F13K50, CDC USB communication and ultra-low power temperature logger

    Quote Originally Posted by tron235 View Post
    Anyone know if this is still an active item PIC18F13K50T-I/SO
    Did you check at MCHP's website http://www.microchip.com/wwwproducts...cName=en533925
    Why pay for overpriced toys when you can have
    professional grade tools for FREE!!!

Members who have read this thread : 1

You do not have permission to view the list of names.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts