RoadTest: Panasonic PAN 1780 Bluetooth LE Eval Kit
Author: jeff_electron
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Mostly the Nordic nRF52840, and its associated development kits, but also a very long list of similar modules which integrate this chip
What were the biggest problems encountered?: the documentation was seriously lacking in some areas
Detailed Review:
This is my road test review for the Panasonic PAN 1780 Bluetooth LE Eval Kit
What is the PAN1780 Module and Eval kit
the PAN1780 module is probably best described as a SoPCB - a System-on-PCB. Its a Nordic nRF52840 Bluetooth SoC put on a tiny module, with some of the hard work of using the Nordic chip done for you.
Panasonic haven't added much on top of the Nordic IC, but what they have done is covered the SMPS supplies, crystal oscillators, and 2.4GHz antenna implementation. here's a block diagram showing that explicitly:
the Nordic IC is a reasonably well featured ARM cortex M4 microprocessor, with an added Bluetooth peripheral comprised of the HF radio part, and also "soft-devices" which are precompiled binaries that handle the protocol for you and present an API.
the Panasonic takes it one step further and presents a very easy way to design Bluetooth into your "internet of things" style product. Its very targeted at a particular application which needs the processing power of a microprocessor, and would otherwise have to separately place an MCU and a Bluetooth modem:
isn't that a wonderful image?
so there we have it. I guess the point is to make it as easy as possible for us to add Bluetooth to our products.
the evaluation kit is little more than the module, along with a debug probe, 5 buttons and 4 LEDs. that's good though, because we're not constrained to using whatever additional feature set the eval kit designer thought was useful to us. instead, we just get the pins!
oh, and a USB hub with an FTDi serial to USB chip:
what am I reviewing?
It might be a little odd that I have to answer this question after describing the Module and evaluation kit above, but its not completely clear to me what the focus of the road test is. in particular:
The RoadTest description is clearly a review of the Evaluation kit, but the Evaluation kit is nothing without an evaluation of the module fitted to it. if you really want to know what I thought of the evaluation kit itself, I’m sure that you can infer it from this review, but I will assume that I am reviewing the whole package. As the end user-designer my ultimate goal is to shove the evaluation kit in a drawer and forget its there, while my product (featuring the PAN1780 module on a custom PCB) ships flawlessly to a boatload of happy (and paying) customers.
The evaluation kit is simply a tool to help me get there, and so that is how I will evaluate it. in some sense, the best evaluation kits are the ones we never touch!
Further, the module is not entirely comprised of Panasonic IP. One of the first things you learn is that the core of the module is the Nordic nRF52840, an ARM cortex M4 MCU specifically designed for BLE applications. In fact, you could argue that the PAN1780 is really just a carrier board for the Nordic IC. The RoadTest programme is clearly engaging Panasonic rather than Nordic, so should I review only the Panasonic contribution to the product?
Well, yes. Except that one of the major Panasonic contributions was to choose the Nordic IC. Clearly they felt that not only was Nordic the right choice, but that this particular Nordic nRF52840 IC was the correct choice. Its almost impossible to interact with this module or Evaluation kit without interacting with Nordic, but throughout this review I will try to maintain a responsibility on the shoulders of Panasonic, and view the Module through that lens.
In simple terms, if Nordic did something poorly, then its Panasonics fault for choosing them and not correcting or improving it.
what is this RoadTest about?
for the RoadTest, I wanted to try to replicate a real-world situation, such as I might find in my work place. The focus of the road test is the usability of the kits, documentation and development environment, because that's one of the most important and often overlooked things when choosing a part to put on a board. of course, price, performance, availability etc are also crucial, but a 10p part without a good datasheet can end up costing you more in development time & re-spins than a well documented equivalent at twice the price!
a well documented and supported part and evaluation kit will help me as a design engineer get up and running quickly, spot flaws in the design idea by actually trying it out, give me something to show off to the boss within a short lead time, and give me confidence that there's at least a chance that my own eventual PCB will work. (even though it never fully does first time). Conversely, a poorly documented or supported kit will cause me stress - especially if I've promised the higher ups to have it ready by the end of the week.
the easier and quicker it is to get going, the more likely I am to want to use the product in a design.
so to that end, my overall goal was to create a "proof of concept" product developed around the module, getting it up and running in as little time as possible. I'm quite busy generally, so I decided that I could afford about 3 days to get this going, plus writing up time (which turned out to be much much longer than I had anticipated!). in any case, 3 days is the sort of time I would be given to do this kind of task at work, so it is probably a good attempt at realism..
when it comes to work like this, creating a demo project quickly is always important, because
As a electronics design engineer, in order to get things up and running quickly I am are interested in:
Therefore, the focus of my review will be on these items
What is the project?
The project itself is inspired by the lockdown!
in March this year I started working from home, and getting most of my shopping delivered. that meant that I never had any reason to use the car. towards the end of the summer, when I had need again, of course the battery was flat, but worse, it had been destroyed by allowing it to deplete so much. I had to buy a new one, which was expensive, and get rid of the old one, which was bad for the environment, and to make matters worse I had to do it on foot, which is slow, inconvenient, and eventually very painful.
if only I had a way to remind me to go and charge up the battery when it was getting low, I could have avoided all of that! so, the project is a car battery monitor.
Its a simple device, which is installed in the car and has to perform the following:
for this RoadTest, I split the work up into 3 phases. I had originally intended for them to be
but it turned out that the three phases were
This is perhaps real life reflected back at me! this section is a brief summary of the three blog posts - for more details feel free to dive in here:
Panasonic PAN1780 RoadTest: unboxing and Cold Start
Panasonic PAN1780 RoadTest: digging deeper and comparing evaluation kits
(part 3 isn't actually published yet - I'll update this when it is)
For part 1 (Discover), I followed through the quick start documentation and timed how long it took me to go from an almost zero knowledge position to an “RF blinky”. It was a little under 6 hours, which I would say is pretty impressive. Time is everything in this game, and that’s a hard bench mark to beat.
Last time I tried, it took me longer than that to just set up the programming environment for the STM32 series (also cortex M4) from ST. and that is with previous experience in several jobs.
For the second part, I wanted to grab a firmware demo and start tweaking the code, but I ended up going down a rabbit hole of frustrated searching for pin mappings between the PAN1780 and the Nordic chip, and comparing schematics. I had to do this because I wanted to make sure that the firmware examples would work with the board. incredibly, despite advertising that there were example applications available, it wasn't clear to me which ones were compatible. there wasn't even a pin to pin compatibility list for the module to the chip, so I had to make one of those first (though I was guessing for the most part!).
the result was that software examples made for the nRF52840-DK were probably compatible if they obeyed the following criteria.
| SW written for the nRF52840-DK is compatible with the PAN1780 Eval kit if it: |
|---|
|
from this point on, I was able to be reasonably confident of using the the software examples for the other development kit, So for the third part, I managed to get stuck in and test out a few things.
My project idea was very simple - I wanted to make a car battery monitor, which would wirelessly send me the battery level so that I knew if I needed to top up the charge.
For this to work, I need an ADC to read the voltage and calculate the State of Charge, and a long range wireless connection to transmit the data from the street into my flat.
The long range, low power aspect of the PAN1780 makes it an excellent choice for this project!
first, I got the ADC working and reporting data back to my phone over BLE. because of the huge quantity of firmware examples, I was able to find one which was reasonably similar to my use case.
In this instance I chose the "proximity" demo, which required a bit of code jiggery pokery but nothing major just yet - just what I was hoping for!
the power supply is simulating a very low battery. the voltage is connected to one of the ADC analogue input pins, but the power is still coming from the PC connected USB cable
I found it relatively easy to get this going, but I did have to mess around with the code a bit to add some features that I thought it probably should have come with "out of the box".
In particular, the code was rejecting a re-bonding attempt from my phone after the link state got itself confused.
That was for some reason a very unstable connection (it kept trying to tell me that my car was getting away!), so I switched over to nRF Connect for desktop:
Better stability, but I had to do a bit of leg work to get the PAN1780 to act as a dongle.
the readings seemed to jump around all over the place, but I was really testing the Bluetooth link battery service. it seemed relatively easy to work with, though there were still some bug-like behaviour I couldn't explain (for example, after the battery went above 100% it seemed to stop sending updates.
I had planned to upgrade the circuit to hopefully get smooth readings at the right voltages for a car battery, but I skipped that bit because I was running short of time. I'll probably do that as an epilogue, so watch the blog for updates!
Next, I did a field test, involving a real field!
I set up one unit facing out of the window of my flat, and went outside with the other to test the range I could get. (I put the other module inside the cardboard box it shipped in to afford it some protection from the elements)
using the coded Phy, I got a maximum range of about 100m, with line of sight (blue arrow in the RHS picture). The orientation of the module made a difference, but only about 10% or so. when I went sideways along the street instead of out into the field, I only got about 60m.
it should be possible to get much more though, here's an article from Nordic which claims over 1km with the coded phy!
its very frustrating that I didn't have more time to investigate these things further, and I put a significant amount of blame on the module being poorly documented, causing me to waste time. I knew the road test was going to be tight for time, but that's exactly how it is in the office.
Having said that, I got the basic components of my design working pretty quickly, and though I didn’t really get to grips with the power section stuff, I did enough to prove that the idea was possible, and I don't think it would take much more to make a working demo of my idea.
what was good, what was bad?
I pitched this RoadTest as a review of the documentation, so perhaps its no surprise that almost every issue I found was in that area, but I think actually this is the only area that this product is a let down. I like a lot about this module, and the Eval kit, but that doesn't excuse some of the more serious problems I came across in the associated support. here's a round up of the worst offenders:
Errors in the Datasheet.
no doubt, documenting this kind of thing is hard! and we can forgive some mistakes without issue, but there is at least one wrong statement that could cause serious issues with a design that uses the module.
here it is:
the word "optional" is repeated in the recommended operating conditions later, but as far as I can tell, supplying a voltage to the HV mode pin is not optional.
The issue is further confused in the module integration guide. it looks to me like the schematic was drawn as if it was optional:
Otherwise, why would JP12 be wired up like that? i've detailed this in the second blog post I wrote, but the conclusion based on the Nordic docs is that its very likely that the pin in fact requires a voltage.
I think that whoever wrote the section about the link jumpers understood this, and tried to suggest that we should remove JP12 in order to somehow apply 5V to the VDDH pin.
applying 5V to a single link jumper pin is tricky and messy, and there's no nearby ground to connect the 5V return to. If this was by design, then the least they could have done was to give us a better connector!
anyway, I think there's no shame in admitting the board contains mistakes, and being clear in the presentation of your data. Many people in a rush to draw the circuit would just copy this schematic, and if I thought the power supply was optional I might just leave it off.
Vague, missing, and confusing information
power supply stuff above included, there were a number of places where the information was presented in a confusing or vague way.
the first thing I got confused by was the naming scheme for the documents, and really this just set the tone for the whole experience.
all of the detailed information on the evaluation kit is found in the "Module integration guide". that's just confusing!
to me, "integrating a module" means adding that module to a schematic I am drawing and will have produced as a custom board.
Although a reference design is useful in this activity, instructions on downloading the software development environment are not!
it would be too much to go through everything in detail, and to highlight only a few issues would probably seem like I was making a mountain out of a molehill, so I'll summarise the issues in a short list:
they are all pretty irritating, and some of them could be very easily solved. there's probably others that I've forgotten about, but i think you get the picture.
It doesn't seem to be part of the Nordic eco-system
even if the things above were fixed, there's still a slight feeling of disconnect when I'm working with the Nordic SDK. all of the tools and tutorials expect me to have a nRF52840-DK or similar, and you constantly have to check with yourself that the page you're reading is relevant.
I also found my self a lot wondering if Nordic we're assuming a level of training that I would have if I had followed their own "getting started" instead.
for example, when I came to use the nRF Connect for desktop for the first time, the instructions I got were:
but what I actually had to do was
was all of that obvious to everyone else? was it covered in the Nordic development kit getting started guide?
There's always a slight worry when you are trying to follow a tutorial that doesn't quite apply to your situation, and I find it slows me down a lot because I'm always second guessing the instructions or googling to see if there's a specific thing that i've missed that makes it all make sense. its not a huge issue, but it could also be solved quite easily by adding it in to the Nordic SDK, or even just noting in the Panasonic documents:
"hey, when you do this Nordic will refer to nRF52840-DK, but don't worry, it'll work just fine with our board too!"
There are also some good parts too
Though Panasonic haven't made the best documentation, there are some other aspects of the PAN1780 module and evaluation kit that are really excellent.
I really like the simple small form factor of the dev-board, and the set of peripheral circuitry is well thought out. I especially like the inclusion of a USB hub, which means that we can consider many different options for serial connectivity in our application:
and it also allows us to get power and comms down a single cable which is independent of the J-link debugger probe - quite an unusual feature I think!
the 100R termination resistors on the IO is a nice touch too.
for the module itself, I think they've pitched it just right by including everything that would otherwise be a risk in EMC testing and or layout, and nothing else.
lastly, I really appreciated having 2 boards to work with. it means that I can consider applications that I might otherwise have not been able to think about, and also that I can do lots of side-by-side testing when I have an issue.
the only real criticism I have of the Eval kit design is that they didn't wire up SWO so we are prevented from using the ITM debug serial connection.
what else might we be interested in?
This review activity has been reasonably focused on the documentation, but there is a wider set of Issues that must be considered before designing a module into one of your products. Here's a round up of my take on the important ones, having spent the last 2 months with this module
1. Its Tiny!
This thing really is small.
At 15.6mm by 8.7mm, I can easily imagine designing this into a “wearable” device, or hiding it in an everyday object to expand the collection of “smart” things. Its not the smallest module on the market, but most of the modules that I’ve worked with in my career have been 2 or 3 times the size of tis one, and that makes a huge difference when you’re trying to add Bluetooth to an item of clothing or similar.
2. Its semi-second-source-able
From a business perspective, one of the nicest things about the module is that it’s so close to the Nordic IC. This means that there are a number of other vendors of modules that feature this chip you can turn to if the worst happens and the Panasonic goes EOL. Even if there are truly no other options you can re-design your hardware to take the Nordic IC on its own and don’t even have to touch your firmware / software implementation. (certification aside, of course)
in total, there are 42 other modules which should be software-compatible:
Here's a list of them all! 3rd party modules/modems - nordicsemi.com
3. Its not that cheap
The module cost in volume quantities is a little under £6 or £7. That’s actually pretty good for this, though by no means bargain basement prices. It’s about double the cost of the Nordic itself, so we’ve got to be sure we understand what we are paying for. There is obviously the supporting circuitry and antenna etc, but that doesn’t make up the difference.
4. BUT, Its got some good Value-Add
And this is what we’re paying that extra money for. Being primarily a hardware engineer who’s done Wi-Fi and GPS circuits and PCBs, I’ve always had one eye on the value-add throughout my RoadTest. I was thinking, “I could do that, what do I need Panasonics module for?”.
Well, here is my answer:
Difficulty in circuit design & layout (crystals / antenna / SMPS)
There’s a few things associated with a product like this that are a bit of a dark art. I’ve successfully done PCB layouts with Wi-Fi, GPS and LNAs (GHz range), mSATA, and ethernet, but I still haven’t worked out how to make sure that 16MHz crystal will work straight off the P&P line. (it ALWAYS requires me to try out various single digit pf caps until I find the one that works across temperature)
There’s always a risk when you layout a PCB with this stuff on it. It might not work as well as you had hoped, it might not pass your EMC testing phase, you might need to do another board re-spin.
Except, of course, if you buy it in already made, which is exactly what Panasonic are offering!
They take care of the crystals, the DC/DC convertors, and the RF antenna all on board with the minimum of fuss. Overall, this is a fantastic service to designers – all I need to do is layout the various digital stuff and provide power, that’s all easy by comparison, and seriously reduces the chances of a PCB error (which makes me look good in front of the Boss!).
manufacturability
Because all of the difficult layout has been done for you, we can go down to as few as 2 copper layers on our own board. Added to this, because the module pin pitch is large (1.1mm, with 0.6mm pad diameter) we don’t need much in the way of special reflow lines or well controlled processes. Stepped stencils are probably unnecessary, and its unlikely to cause problems at reflow. Compare this to the Nordic WLCSP, where I would have to go for the more expensive 4 layer board with impedance control as a minimum, and my BGA pitch is 0.35mm, and all of a sudden my PCB and Assembly costs have gone through the roof, and the production line yield is too low because 350 micron pitch BGAs require real care and attention.
These 2 are roughly to scale!
Qualification
Finally, perhaps the biggest headache when adding RF comms to a product is the rigorous certification you have to go through. Modules like the PAN1780 have one huge advantage over the bare Nordic IC, which is that they include the antenna. This “self-contained-radio” feature means that in most jurisdictions, for most testing standards, the regulatory body will accept an overriding master qualification test certificate, and that is provided by Panasonic.
Here it is for the USA:
FCC ID: T7V1780
That ID, stamped on the side of your USA product, is going to save you a lot of money on expensive certification processes that you would have to do yourself with the Nordic IC
Closing thoughts
Ultimately, it all comes down to one question: would I design this module into my product?
yes.
I probably would. its obviously got to compete on price (which I can't evaluate without ringing up several vendors and pretending to be a wholesale customer), and I would probably want to test the direct support lines a little before absolutely committing (i.e., asking questions of FAEs, seeing if I could get hold of the CAD project files), but in the end I think this is a good effort with useful features.
I would of course also need to iron out the niggles with my project demo detailed above, but I'm almost completely sure that that's user error (aka, me)
Top Comments
Hi Lara,
thanks for reading my review, Its nice to know that Panasonic are taking an interest!
Thanks,
Jeff
Thank you Jeff, for your effort and your work with our Evaluation Kit! We really appreciate your feedback!
My name is Lara von Rhein and I am Product Marketing Manager for Wireless Connectivity at Panasonic…
Hi Lara,
yes of course, that's no problem.
sorry for the slow response, I didn't see this reply until now. (been very busy the last few weeks)
Thanks,
Jeff