Ideas for reworked UBW32

Hello all,

Recently I noticed the comment on the [UBW32 products page about a new, revised version being planned. For a while I have been eyeing this nifty little board, as I am considering building an Open Source project around it. It would take a bit to explain exactly what I have in mind (and I’d prefer for it to be a bit of a surprise), yet basically the PIC32MX360F512L is one of the few embedded chips I know of, which has the I/O pheripherals and the CPU horsepower to do what I want it to do.

However there is one major stumbling block in the UBW32 board, which have me hesitating. My project need many if perhaps not most of the high speed pheripherals, and most all at once: Parallel and serial I/O, A/D, capture/compare, PWM. This has me worried about the very compact design of the UBW32 with only a very rudimentary layout for the ground connections to the rest of the world.

For many low speed hobbyist projects the current design is probably fully adequate. However if you are planning on actually pushing the chip’s I/O capabilities, then I rather strongly suspect you will run into very serious cross-talk issues with a subsequent drop in dynamic range due to shared ground connections. Proper grounding is a serious issue when designing and in particular mixing analog and RF equipment, and I would be very interested in hearing if any testing has been done in this regard with the UBW32.

More specifically: Each and every ground leg on the PIC32MX4x should have its own VIA - or better yet two - connecting to the rear of the PCB, preferably close to its associated 0.1uF supply decoupling capacitor. All these VIAs connect on the rear to one large, unbroken patch of copper foil directly below the chip. The patch of unbroken copper foil should have a large-ish rectangular or square area free of lacquer and pre-tinned for easy soldering.

This would allow the interested experimenter to mount the board, say, edgewise along another piece of bare PCB, intended for shielding and grounding. A short strip of copper foil or -braid could then be soldered between the two boards, with sensitive I/O signals being routed directly to the central ground connection. This is known as star grounding.

Bonus points for bringing some of the ground connections directly from the chip and out to the edge, spaced in between the regular I/O connections. This would allow for even better opportunities to separate ground signals as and when needed, though it would obviously require breaking pin compatibility with the current layout.

Another point maybe worth considering would be to add a solder pad for connecting an external crystal oscillator. For my application I suspect some (most?) users would like a long term stability of the master oscillator of 10 (ten) ppm or better, and I have my doubts as to whether the tiny crystal used on the UBW32 is able to achieve this. Having the ability to break a PCB trace and bridge a solder pad to connect an outside oscillator to pin OSCI would be very nice for some high precision applications. Personally I would like to add an external crystal oven for my personal implementation.

Note that the planned addition of a 32’768 Hz crystal doesn’t help here. It is the master oscillator for the high speed pheripherals and timers, which needs to be stable over the long term (minutes, hours).

As it stands, then the board is not too attractive for my project, and I suspect by extension the same may be true for many similar ones trying to push the envelope. I can probably modify the board to work for me by reworking the surface mount components. However that would mean other people would have to do that as well if they wanted to copy my project. That sort of ruins the whole idea of having a break-out-board for these tiny multi-legged monsters.

I can add a whole lot more detail here if needed. :smiley:

The board is very cheap compared to your time. Get the board, build what you want to build, and then see where you sit performance wise. If you need much more performance, then you will have some very clear goals and you can put your ideas into play.

20 years ago we used to worry about all that you mentioned a lot. Today 480 Mbps USB is talking to ~200 MHz FPGA which lives near a 16-bit ADC…all on a 2 layer PCB and its glitchless with 15 bits of resolution.

Greater noise margins, power supply rejection ratios, on-board references, lower overall currents, CMOS switching instead of TTL, etc, have helped dramatically.

Thanks for your reply.

Maybe I didn’t explain myself clearly enough. It is not about me or my current project as such.

What is the purpose of the prototyping boards sold by SparkFun?

Assume someone develops a fun and generally useful open DIY project intended for individual experimentation and customisation. Having used a board from SF, is he or she then supposed to:

A) Point his or her audience at the SF webshop for their respective board needs?

  • or -

B) Look at the hacks required to make the SF board work as intended, and start to produce his own boards in competition with SF?

  • or -

C) Not start working on the project in the first place.

I would hope the answer is A), as I personally have no interest in starting a business similar to SF.

If A) is indeed the answer, then:

*) I am of the impression a new revision of the UBW32 may be in the works.

*) To my eye there are some modifications that could easily and inexpensively be done to the board, which would make it easier for someone like me to demonstrate best practices when it comes to physical arrangements of components etc.

It looks to me that the board space below the chip is currently unused, save for showing SF’s logo in black. The board already uses VIAs, so the added cost of a handful more, moving or rescaling the logo and adding a solder patch, like the footprint of a SMD power transistor, would be insignificant.

Currently I can only speculate what the reason was for locating the main pair of ground connections as far away from the chip as seems possible. They even share the ground connection to the PSU regulator. For the same pin count and form factor there is no reason not to locate the ground connections at the center of the long edge, right next to the chip.

*) Secondly, if - as I suspect - the small crystal has a temperature drift in the hundreds of ppm, then it is fairly pointless to sing the virtues of the chip’s 32 bit pheripherals. The current crystal is certainly more than adequate for proof of concept work and general development. However if you intend to demonstrate how to use the board as part of a real world application needing the precision of 32 bit I/O, then you absolutely need to be able to connect an external, high stability oscillator. This has nothing to do with this chip or the particular board layout, it is just plain physics.

For slow chips with 16 bit precision, sure, the onboard oscillator is probably most of that you’d ever need. But this is one of those cases, where you cannot just scale a design to higher frequencies and precision.

Turn the chip 180 degrees, so the oscillator pins goes opposite the PSU and USB components. Use the space currently occupied by the ‘house’ logo to add a few solder pads and a pair of through hole connections for an external connection. Again close to zero cost, save for the board redesign.

On the given evidence there is no apparent reason I can see for not doing the board ‘right’.


Finally, I will have to admit that it has been 10 years since I last made a living from this stuff. These days I am just a hobbyist.

However unless I completely miss my mark, then best practices when it comes to grounding and shielding hasn’t changed one bit since then, improved technology or not.

There are plenty of current war stories doing the rounds about people not doing their homework on this subject. The nice people at [Analog Devices can probably tell a fun story or two here if people are particularly interested.

Frank,

All of your points (as far as I can tell) are completely valid.

An you know what? It’s an open source design - you are more than welcome to make an improved version! I would absolutely love it! Maybe SparkFun would even sell it. :slight_smile:

The ‘new version’ has very, very few changes from the current version. None of the changes you recommend.

I have had ground problems when pushing both SPI buses to their maximum speeds too. I agree with everything you say.

The reason the board is designed the way it is was to put on a single breadboard. Also, it had to be only 2 layers. Also, it had to use 10 mil lines 10 mil spaces. Also it had to be as small as possible. Also it had to have components only on one side. Also it had to be as inexpensive as possible. Also it had to have every I/O pin come out to a .100" header. Also, I had to develop it in my spare time, as a learning experience (and it certainly was that) as a purely software guy. :slight_smile:

I’m not trying to make any excuses - I think the UBW32 is really cool and fits a need. But from your perspective it clearly needs improvement. That’s awesome. You need a board that has really gone through an EE design and review process, where you consider ground bounce and signal integrity issues for every peripheral. I strongly encourage you, nay, I challenge you, to design it ‘right’. Keep the schematic the same (so that they’re compatible) and improve the layout. It would be wonderful- you clearly know what you want and how to get it, so go for it.

Would your suggested modifications be easy and cheap for me to make? No. I don’t have enough experience to do what you suggest and keep the form factor the same. I went through nothing less than 3 complete re-routes even getting to the point where it is today. It was extremely hard for me. Based upon your experience, maybe it would be easy and cheap for you to make your proposed changes. The world would be a better place for it.

Do most people need a crystal with better temp stability? Nope. Why not? Because the current one will run USB (which has a pretty tight tolerance requirement) all day long at room temp. Do most people use UBW32s at temps other than room temp? Nope. I’m sure some particular uses of high speed peripherals will require a more accurate clock, but I believe that they would be a small minority. If so, the user would probably understand enough about what they needed that they would opt for a different prototyping board in the first place.

Do most people need better grounding so that high speed digital signals are done properly? Nope, I don’t think so, although I could be wrong. Many, many companies (who know FAR more about how to do this kind of stuff than I do) use the UBW32 every day for prototyping new PIC32 products. And so far none of them has written to me about improving the UBW32 in this way. (Although they could just be grumbling to themselves.) I’m not saying your suggested improvements aren’t valid - rather that most people don’t seem to need them and thus I haven’t considered spending the time to learn enough about how to make it a reality.

I love the feedback, and welcome it from everybody.

*Brian

When is the UBW32 going to be released? ie with 128K of RAM?

According to what I understand (and remember, I am NOT a SparkFun employee, nor do I know exactly what they’re going to do, so this is a very educated guess) there will be two versions of the UBW32. The first one will use the existing MX460 CPU, just as the current UBW32 does. But there is a slightly updated board layout, (including a spot for a 32KHz crystal and a better main crystal) which is why there’s a new version. This one should be available in, oh, I don’t know - a month maybe?

Then, as soon as SparkFun can acquire some MX795 CPUs (the one with 128K RAM), they will switch over to using that CPU. The board is identical except for one silk screen element. Right now, Microchip isn’t able to provide CPUs in quantity for several months because it is so new.

*Brian

I understand… I’m working on the eLua port to UBW32… I got side track for several months with other contracts so… now getting this done…

Brian,

Thanks for your reply, appreciate you taking the time to write it.

Somehow I still have this nagging feeling that we are talking slightly past each other here. Please allow me to spend a bit of time explaining exactly what my application is, then we can take it from there. It is getting late here and I’d like to give you at least a partial answer today before heading for bed.

As it happens, then I realized I was just being silly by trying to hide exactly what my project it. By its very nature then it cannot be ‘stolen’, since it wouldn’t work as a closed source system. And if somebody else start working on this before I get around to it, then it would just serve to save a lot of time and initial work for me on the prototype.

Right. Please fasten your seat belts, here we go…


Around the world there is about 1 million active radio amateurs aka. ‘hams’. Today, when a ham wish to get his hands on some radio equipment, he has the option of either buying some factory made equipment, or building his own. (Unlike the CB/walkie talkie operators we are allowed to do this).

However, for the last few decades or so, the art of analog (RF) DIY among radio amateurs has been in a steady decline. The trouble is that the corporations making and selling radio gear for the radio amateurs are all very large with vast resources available to them during development. The net result being that it is nigh impossible for almost any single individual to design or copy a complete radio, which has anywhere near the same functionality as a factory made design.

So today most new (and sometimes not so new) hams never really get started in home construction, or their experiments end up being fun little gizmo’s, which you mostly cannot really take seriously for many of the usual ham radio activities: Worldwide activity contests, long distance communication (Earth-Moon-Earth), satellites etc.

The sticky spot has always been the control of the radio. Modern radios have enourmously complex human control interfaces, [up to and including full flat panel displays on the front panel.

Yet in reality little has changed since WW-II when it comes to the actual analog radio parts and building blocks inside a communication radio. Most of what you see in a modern radio is just the result of one (or rather, usually several) powerful MCUs at work. The analog part of the radio is actually not too hard to replicate, surprising as it may seem. Yet with the tools available to the average experimenter, replicating something akin to an IC-7800 is an almost hopeless endeavour due to the software needed for the controls and dsp processing.

Many have done experiments with using MCUs and PCs to control DIY ham gear, of course. Yet mostly you end up with something way too underpowered, like when you try to use a single 20 pin PIC. Or you have your ‘radio’ [permanently tied to your PC, using that one instead for the HID. To my knowledge there are no really flexible, Open Source and thus fully modifiable radio control projects out there, in kit form or otherwise.

Now enter from stage left a little corporation called Microchip. As you will be aware, then a few years ago they released a new family of microcontroller chips.

And into this Chip, they poured all their cruelty, their malice and their will to dominate all life. One Chip to rule them all.

Ahem :shock: (Sorry, got carried away there… :smiley: )

This thing has everything you need to build a radio experimenter’s dream development and experimentation platform. Plus the kitchen sink.

Main sticky point with previous MCU platforms was the immediate lack of ability to do main frequency control.

Variable frequency control in DIY radio equipment is traditionally done via a low phase noise voltage controlled oscillator (VCO). Direct digital synthesis (DDS), like used in the AD98xx and AD99xx devices, is rarely able to achieve similar levels of performance. They can be OK-ish for simple radios, but are not easily tweaked to serious, world class performance. (Sorry AD…)

However a free-running VCO rarely has the long term stability needed for a communication radio. It drifts, if slowly, so it needs to be controlled somehow.

One way of doing this is by having a MCU interface with a frequency counter. It samples the VCO for a fixed time interval, usually a fair fraction of a second, and compares the calculated VCO frequency with what the user expects, the ‘dial frequency’ if you like. The MCU then slowly adjusts a high resolution control voltage, which is fed back to the VCO to gently nudge it back on track.

On the PIC32MX plaform we have 2x 32 bit counters, which can be directly clocked at up to 40 MHz. And there are up to 5 PWM outputs, which can achieve around 18 bits of D/A precision with an update rate of a few hundred Hz. With 32 bit precision, a prescaler and a longer sampling time we can easily make accurate frequency counts up into the UHF/GHz range.

Dude! :mrgreen:

Additionally:

  • - Low price. Burn one out? Buy another. Need more CPU power still? Add another.
  • - Enough processing power to drive flat panel displays and real time analog processing.
  • - Integrated A/D converters, 10 bit @ 500 ksps. More than enough for audio post processing.
  • - I2C and SPI for high speed audio DACs and other integrated I/O devices. EEPROM can be added for saving configurations and calibration data.
  • - Silly amounts of memory, both RAM and program.
  • - More I/O pins than you can shake a stick at.
  • So the plan is to develop a base software platform, which allows the interested experimenter to easily integrate his PIC32 with a vast array of standard hardware interfaces, intended for radio control. There is enough program memory in the device to accomodate quite a few ‘hardware drivers’, all responding to the same basic program and communication structure. A more or less complex RTOS core will also be there to control data plus resource control, like allocating I/O pins to the different drivers. May be nice to have some form of voluntary resource control etc. (FreeRTOS? No idea yet…)

    An individual experimenter now just have to choose which hardware interfaces he wishes to use/build, and write/link a relatively simple program to tie everything together. One can even imagine a number of standard configurations, where no programming is required on part of the experimenter. You just calibrate your configuration via a simple user interface using push buttons plus a frequency readout display etc.

    Some of the I/O devices I have in mind are:

  • - Frequency counter input combined with PWM D/A output for fine grained VCO control. Main selling point of the device configuration. Theoretical frequency resolution of about 4 Hz with a linear 1 MHz VCO control range (VCO’s usually aren’t that linear though…)
  • - Matrix keyboard/pushbutton inputs.
  • - Analog/audio I/O for DPS post processing (synthetic stereo for Morse code reception? Yay! :backflip: )
  • - Quadrature decoder for continuous rotary controls, like frequency input.
  • - Simple potentiometer input for inexpensive frequency control. Combine input from two potmeters to achieve required dynamic range, as 10 bit resolution is way too little. 5 A/D channels makes this easy to do, even when combined with the need for audio input.
  • - LED (7 segment) and LCD (HD44780 etc.) frequency/HID readouts.
  • - Flat panel displays: Complex HIDs, waterfall frequency and spectrum displays etc.
  • - Analog meter output (PWM, serial D/A): Power and signal strength meters etc.
  • - Plus a few more devices, which I really wish to keep as surprises for now. :wink:
  • Right. This must be enough detail for starters. I will pick up on this later where I left it.

    Sweet dreams everyone.

    • Frank.

    (Mike Oldfield: Ommadawn + TSoDE)](http://www.flex-radio.com/)](http://www.icomamerica.com/en/products/amateur/hf/7800/default.aspx)

    Frank,

    I think your vision is beautiful! I really want you to build it!

    I know very little of radios, but I still think that if you either a) know that the UBW32 would not work for your application because you have tested it and it failed, or b) from past experience can look at the design of the board and see that it would never work properly, then you (or somebody else) should re-design it so that it would work for your application. You’d probably want to have nice high density connectors down to whatever base board you’d use. You should probably go four layer so you can have a ground an power planes. Etc.

    One thing to keep in mind is that there are an enormous number of 32-bit CPUs that have approximately this level of power, memory, and peripherals. Many are cheaper. Some may even be a better fit for what you have in mind. (Blackfin? OMAP? Lots more signal processing horsepower on those guys, but more expensive than PIC32.)

    Isn’t there a software defined radio project in existence? Wouldn’t they have the same type of goals you have for your project?

    You started this thread saying that it should be trivial to re-route the UBW32 board to significantly improve its performance in certain applications. I am unable to make this change, so maybe you or somebody else who understands what you need could do it? I still feel that making the types of changes you suggest with the current board dimensions would be difficult, but I’d love to be proven wrong.

    *Brian

    Confusing detail edited. Please see note at the very bottom of this post.


    Right, I will try to be somewhat brief. You have brought up a fair few subjects, which I wish to comment on.

    *) Redesign of the current UBW32.

    I have now had time to look very closely at the current board layout for the UBW32 (v25). I will have to backtrack on my words, as it may not be as easy to modify it as I had originally thought when just looking at the board photos. In other words this thread is null and void…

    In particular you have been forced by the form factor to ‘fold’ many of the connections in under the MPU to get enough ‘width’ for all the connections going toward the end of the board. This leaves many more VIAs in under the MPU than I expected. Additionally it looks like the open copper below the MPU is used for Vdd routing and not Vss as I had assumed. That would have caught me by surprise for sure, if I had attempted to modify the board by hand.

    *) Form factor.

    By your own words you choose the form factor first, that the PCB had to fit into a breadboard, and then you had at all cost to squeeze everything onto the resulting PCB.

    Unfortunately that in itself is a mistake IMHO. In my world breadboard is great for beginners, who are tinkering with a few opamps and some discrete components. However for any kind of serious prototyping work involving either higher power (motorcontrol, power supplies, amplifiers and more), high component count or high speed (about one MHz or higher), you really need a much better way of building stuff. Yes that means you do need to solder everything together, no excuses accepted. That is one lesson I learned the hard way decades ago.

    What tend to happen, unfortunately, is that people start out in electronics building stuff on a breadboard. Initially everything is great. Their low-ish speed stuff with a few LEDs and low pin count MCU’s work great, and they are having fun. So naturally people assume they can just continue building more and more complex setups this way. Eventually things do fall apart, and they are left with no apparent way out and no obvious explanation for their troubles.

    Yes, I know people have been building radios and whole digital controllers on breadboard. It is an abomination, and people need to learn how to build stuff properly, so their designs can be relied upon.

    Designing a breakout board with I/O potentially running at up to 40MHz and using a 100 pin device, intended to be used on a breadboard, is an … interesting idea IMHO. :smiley:

    *) UBW32 functionality.

    I have not tested the UBW32 myself for high speed operation, but I have worked on many similar projects, including industrial control applications (mostly based on TI’s TMS320C3x and TMS320C6x MPUs), and have seen my share of high speed electronics, up to and including 10 GHz commercial radar. Seen = soldered in and worked on.

    In my humble opinion you basically managed to break just about every rule in the book when it comes to MHz electronics. Your only saving grace is that the board actually isn’t that large, physically. Based in this it is my evaluation that you are potentially going to run into problems of different sorts, if you tried to make full use of the functionality of the PIC32MX. Can I make a guarantee? No, but I won’t be surprised.

    I am however quite prepared to take arguments from the audience to the contrary. Don’t be shy.

    Make no mistake about it. If you just use the I/O at relatively low speed, not used all of it, or didn’t care too much about noise, dynamic range and similar issues, then the board is likely to work great. That means it is still excellent for testing, or for applications having relatively low speed I/O, and where the meat of the chip is mostly used for storing application data and doing number crunching (maps + AI?). Note that most motor control applications counts as low speed in my book, unless you have been doing way weirder things than I have.

    *) [“Not the cheese, Gromit!”[/b]
    You are not guessing correctly when it comes to what I want from the board. Basically you get everything right, except the PCB layout. Components only on one side, dual layer PCB, 0.1" connector pinout spacing, schematic and functionality are all fine with me. That is why I am sitting here, slightly frustrated and wishing I could somehow ‘fix’ the current layout without breaking backward compatibility.
    If I were to design an UBW32 mk. II, then it would basically be the same thing, save for a slightly different form factor and probably a bit larger board area as well. Wouldn’t be larger than half an Euro card (80 x 100mm) though, and probably smaller than that. Might use a few (~ 5) additional decoupling capacitors, but that would be about it. What chips are U2 and U3, please? Doesn’t seem to be written anywhere.
    My plan at this point is to get a friend to buy me a pair of UBW32s from SF for me to tinker with. That should get me off the ground and get my feet wet with the PIC32MX. Then, once I am back up to speed with Eagle, I could design my version of the board, how I think it should be done. Would probably be easier to explain my concerns if we have each our version to compare. Wouldn’t mind writing them down though if you wish.
    *) Choice of MCU.
    I am definitely not up to date with the current choice of modern MCUs, and wouldn’t mind a hit with a clue-by-four if anyone has some hints. I did look around a bit, and was unable to find anything more compelling than the Microchip PIC32MX models, given my constraints:

  • - Chips generally available to anyone, in any quantity. In other words chip manufacturer must be hobbyist friendly.

  • - Chips must be relatively easy to physically work with for low budget outfits and hobbyists. No BGAs, no clock or bus frequencies in the hundreds of MHz range. Designing boards with that kind of speeds in mind does require access to modern (and ultra expensive) CAD tools.

  • - Development kits at low cost for mortals. I don’t expect people want to pay $1500 for one of TI’s development boards for the 'C2000…

  • - Free development tools available to anyone. "Here is the download button. Have fun!

  • - Long term support by manufacturer.

  • I also looked at ARM due to that core more or less being an industry standard with support from many manufacturers. However I didn’t really find anything, which could stand up to the PIC32MX. True cross platform development tools would have been nice as well.
    *) Software Defined Radio (SDR).
    I wish my project to be the opposite of SDR, not just another SDR. There are tons of different SDR projects out there.
    In a SDR, you either buy or build - frequently from a kit - all the analog guts of a radio, and put them inside a closed, black box. At one end there is a connector for an antenna, and at the other one or more high speed A/D and D/A converters. Add a high speed network connection, which quickly pipes real time data to and from your PC.
    Then we end up with a bunch of people sitting in front of their PC, pecking away at their keyboards and trying to pretend they are having fun. Well, those few, who are able to develop DSP algorithms, probably do have fun. But no soldering iron in sight, and no insight gained by the majority of users. Certainly none when it comes to the actual RF bits and pieces.
    In my project you could start out with a basic digital configuration, for instance: PIC32MX board, EEPROM, matrix keypad, LED or LCD display and one of those cheap, rotary quadrature encoders. Then the world is your oyster.
    Now ‘all’ you are missing are all the interesting analog bits and pieces: Oscillators, amplifiers, mixers, filters, fancy analog human interfaces(!), power supplies and more. You can start with something very simple and very cheap, and just build and expand over time as interest, money, experience and time allows. You can build, tinker with and learn about all the parts that most ‘electronics’ people try to ignore and pretend no longer exist or are relevant. And as your project and experience grows, your radio can do all the fancy control things all the applicance radios has as showpieces. I also intend to try and collect a library of schematics for analog building blocks for radios at different levels of price, performance and complexity.
    I am not aware of any other project of this nature. Please do tell if you do.
    “Yes, your new Gizmotronic 9000 is pretty cool. But I made this one myself.”
    Steps down from soapbox…
    - Frank.
    ****
    NB: Edited in ‘breadboard’ instead of ‘prototyping board’. Apparently there is a difference in English here. Sorry about the confusion.](http://wallaceandgromit.net/)