1
\$\begingroup\$

Ok, this is my very first question here so please forgive me if I'm asking a too broad question or if my problem description is too imprecise.

I have a 13.56 MHz (RFID) pierce-type quartz oscillator from which I have to derive a burst packet of exactly 136 periods (~10us burst length). There is a trigger signal (TRIG) available to trigger this 10us burst. [Edit1: TRIG is fed to a 74LVC1G126 buffer driver which enables/disables the burst]

The problem: I need to do it cheap (<10 cents @ 10kpcs) and space constrained (somewhere below 40mm^2). So a microcontroller is not an option. RC timing is also not an option considering the required temperature range from -20°C to +70°C.

I think I need some type of discrete, synchronous counting circuit.

My first idea was to use a SN74LV161ADGVR type counter which is available in a 6.4x3.6(TVSOP16) housing, but it has only 4 bits and 6.4x3.6mm already scratches at my space constraints.

Do you have any idea how to achieve such a tiny,cheap burst controller/counter fed by a crystal oscillator?

\$\endgroup\$
  • 2
    \$\begingroup\$ by the way, re "can't be a microcontroller": If you can pick what's currently cheap on the market each time you do a 10k production run, you can get MCUs below 10cts, for example this one (but this one is 36mm², so might be maxing out your size, without external capacitors etc). \$\endgroup\$ – Marcus Müller Aug 3 '18 at 7:49
  • 2
    \$\begingroup\$ Try and use a micro and use it also to mop up another $0.20 of components not associated with the pulse counter. Look at it as an opportunity to cost save. \$\endgroup\$ – Andy aka Aug 3 '18 at 8:14
  • 1
    \$\begingroup\$ What @Andyaka said. For example, your Pierce oscillator needs some kind of inverting amplifier to run. Just use the crystal as external oscillator for your MCU; you'll save one amplifying component! Many MCUs can directly output their own clock \$\endgroup\$ – Marcus Müller Aug 3 '18 at 8:20
  • 2
    \$\begingroup\$ @StefanWyss occasionally, you'll see cheaper things; I'm also pretty sure that consumer appliance manufacturers don't pay 10ct per toaster to make an LED blink,but 10k is probably not the amount with which you can approach Renesas for cheaper MCUs in bulk,and a Swiss engineer salary probably doesn't allow for you to fiddle with the cheapest the Chinese market can offer until it works and not compensate your component savings by R&D cost (that's a narrow path you're walking–if you safe say 4 Rp. per piece, and only produce let's say 20.000,how long can you work on that w/o reversing the effect) \$\endgroup\$ – Marcus Müller Aug 3 '18 at 8:27
  • 2
    \$\begingroup\$ @StefanWyss I think you can get an exception to that rule if the MCU's only job is to count to 136 :D (that number is not going to change, and there's not going to be desire to change firmware) \$\endgroup\$ – Marcus Müller Aug 3 '18 at 8:38
3
\$\begingroup\$

I'd like to think a microcontroller will probably save you money in the overall design – less to pick and place, hence lower assembly costs, and the potential to incorporate functionality that otherwise would need more dedicated hardware (e.g. the inverting amplifier for the Pierce oscillator typically comes built-in with a microcontroller).

Now, if you want something more hardwired-ly: there's programmable hybrid logic / analog chips.

Silego (now dialog semi, it seems) has something they call GreenPAK, think a small one-time-programmable FPGA and analog array, and if you're working with a company with a good purchase department, then I'd guess the 13.5 ct they want a piece for their smallest variant (which definitely seems capable enough of waiting for an enable pulse, then passing through a 13.56 MHz clock, until it counts to 136) is negotiable; nice thing is that it's the price for a part coming configured with your design.

http://www.silego.com/buy/index.php?main_page=product_info&cPath=67&products_id=491

\$\endgroup\$
  • \$\begingroup\$ I rate this answer as a solution to my problem. My fault: I did not mention that my circuit has to be low-power. But I think it could work with this tiny little beasts. I just need to find out the details of the design. Thanks! \$\endgroup\$ – Stefan Wyss Aug 3 '18 at 11:55
2
\$\begingroup\$

First of all, you'll need a latch that enables your output on your external pulse, and can be disabled again.

The simplest latch contains an NPN and a PNP and two resistors. NPNs and PNPs can be bought in the same package cheaply (nexperia and others offer such standard configurations, example; there's even "resistor-equipped" versions of that).

A discrete solution is a bit hard – of course, you can build a 136-counter, but counting to 136 either takes a lot of concatenated smaller counters (breaking both space and cost constraints).

Or you use one counter to divide your clock, and then another counter to count until you reach the remainder:

136 = 2³ · 17¹

So, use a 3-bit counter to count to 8 (the third bit toggles with a frequency of f_in/8).

Then, you only need to implement a counter-to-17:

Build a counter-to-16 and a single-clock delay! So, an 8-bit counter, and a flipflop.

Then another NPN + resistor to turn off your latch.

\$\endgroup\$
  • \$\begingroup\$ Thanks for your answer. Still I would not accept it as the solution because of the space and cost constraints. I have already solved the enable/disable of the burst: I can take a 74LVC1G126 type buffer driver. \$\endgroup\$ – Stefan Wyss Aug 3 '18 at 10:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.