Table of contents

RoadTest: Panasonic PAN 1780 Bluetooth LE Eval Kit

Author: parasquid

Creation date: 13 Nov 2020

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?: nRF52840DK, nRF52DK, Pixl.js, Waveshare nRF52840 Development Board, Adafruit Clue

What were the biggest problems encountered?: The header pin configuration is symmetric so it's prone to accidental reversal of polarity when developing a shield-like attachment system. While there is voluminous information about the nRF52840, specific support for the product and the eval kit is almost nonexistent; their forums are a ghost town. Documentation for the eval kit isn't very comprehensive and does not give an easy way to access headlining features of the nRF52840 module (e.g. being able to use high-voltage mode, using a low frequency crystal, etc).

Detailed Review:

Introduction

I'm going to steal baldengineer's intro to his sweet and concise review of a buck regulator evaluation board as I'm also currently torn with what to review: the silicon that Panasonic Industry is trying to show off (which in this case is the nRF52840), or the actual usability of the evaluation board (the PAN1780 Evaluation Kit).

Much like his conclusion: I'll try to do both.

Over the course of the road test I've done a few experiments and projects and documented them in a blog. This roadtest review will be summarizing the findings in those blogposts, so you might want to start with those first.

• Road Testing The PAN1780 Evaluation Kit (part 1) - Unboxing and First Impressions
• Road Testing The PAN1780 Evaluation Kit (part 2) - Throughput Comparisons
• Road Testing The PAN1780 Evaluation Kit (part 3) - Home Automation via BLE Advertising and MQTT
• Road Testing The PAN1780 Evaluation Kit (part 4) - Controlling a Smart LED Color Light Bulb with Web Bluetooth
• Road Testing The PAN1780 Evaluation Kit (part 5) - Air Quality Dashboard via Web Bluetooth

I'll also be talking about some of the projects I've planned but didn't get to do, due to either lack of time and resources or inability to execute due to the board not exposing the necessary peripherals needed.

Comparison with Other Development Boards

When I started the roadtest, I had with me some nRF52840 based development boards. I thought making a comparison between them would be useful so I made a round-up of their feature sets and compared them against each other.

* AdaFruit CLUE has test pads for SWD

* PAN1780's JLink OB is accessible via jumpers, but does not give the full "debug out" functionality

The Good

There certainly are a number of good things about this board. I'd like to start this off by talking about what the PAN1780 Eval Kit did well and I wish other development boards would also implement.

Small and Compact Size While Retaining the Important Stuff

This is probably the headlining feature of this evaluation kit: it does mostly the same things as the nRF52840DK while being almost a third of its size.

While the nRF52840DK exposes as much of the nRF52840's pins and capabilities, the PAN1780 shares the same philosophy even when dropping some extra baggage along the way. Sure, we don't get as many of the pins available, and we likely won't be able to use this evaluation kit for prototypes that involve the usage of so many GPIO (which brings the question: maybe a GPIO multiplexer would be a better idea?) but we also don't get a huge development board that can sometimes be unwieldly.

Using the Nordic nRF52840 Development Kit as the inspiration and reference makes it very useful for a developer because this means that most examples in the nRF52 SDK can be flashed and run as is, without any recompilation. I found this really convenient, as I didn't immediately have to learn how to use Segger Embedded Studio or Keil just to check out the SDK examples.

For instance, there are SDK examples that work with LEDs and Buttons like the ATT_MTU Throughput Example, which I was able to flash and try out on the PAN1780, nRF52DK, and nRF52840DK.

I didn't have to remap GPIO or do workarounds for the PAN1780; everything worked as is. I wasn't able to use the example binaries to test my other development boards though, as their GPIO assignments for these peripherals were different (e.g. lack of buttons or notification LEDs).

Built-in Programmer and USB to Serial Adapter

I've started playing around with some of the bare chips I ordered from Minew (another manufacturer of nRF52840 modules) now that the road test is over. I I didn't know how good I had it with the PAN1780 until I realized I had to fish out my JLlink EDU programmer from storage. I found that I really missed having an onboard programmer while doing prototyping work since I didn't have to fiddle with extra wires and cables; all I needed was to plug in a Micro USB in the development board and that was it.

The same goes with the USB to Serial Adapter. While it wasn't as big of a deal when I'm using Espruino as the serial console is passed through the Nordic serial port emulation service over Bluetooth Low Energy, I had to use a separate USB to Serial Adapter when I tried to use the Arduino framework to try out some libraries.

I felt that if I had the adapter onboard and not as a separate peripheral it would have been a lot more convenient. More so if I needed to have both programmer AND serial adapter connected; that would have been a mess of wires just to get something up and running.

Of course this only really applies to a development board, since I wouldn't want these built-in adapters together with my final circuit. So I guess the real lesson here is not to use bare chips and modules for doing development and prototyping, but instead use a development board that has these onboard adapters (like the PAN1780 Eval Kit) for that.

Jumper System for Configuration

Some development boards require the use of solder bridges to enable or disable functionality. These are a bit difficult to use, especially if the solder bridges are tiny and difficult to reach with trembling hands. For example, I almost bricked my Waveshare Evaluation Board because I accidentally lifted the PCB traces while trying to solder some wires to the test points for current measurements.

The PAN1780 Eval Kit on the other hand makes these things easy by having all of the pin headers in a 0.1in grid spacing, which enables the use of readily available DuPont style connectors everywhere. It also allows the flexibility to disconnect certain circuitry like power to the 5v or 3v3 header pins, or peripherals like the onboard programmer or serial port, just by removing the jumpers.

The biggest (possibly unintended) benefit with this jumper system is that you can reuse the j-link programmer for programming other chips. It would serve well in a pinch, but I would still suggest getting a standalone programmer for that use case.

The Bad

As we've seen, the PAN1780 Eval Kit checked many of the right boxes. There are areas though that I felt were not going in a good direction, and would probably need a rethink. Some of those areas are the following.

Symmetrical Headers with Power and GND at the Tips

I realized this when I was doing the NeoLightbulb project: I could have destroyed my circuit if I plugged in the adapter board for the lightbulb the wrong way around!

Since the GND and the power supply pins are at the opposite tips, and since the headers are symmetrical without any visual nor physical indication of which side is which, there is a big possibility of plugging in a top or bottom adapter in incorrectly and cause a reverse polarity situation.

I'm not sure why this particular layout was chosen, but that project took me some time to build not because it was complicated, but because I kept second guessing and double checking whether I plugged in the lightbulb adapter in the correct orientation.

This could have all been avoided easily, and it's not exactly an unsolved problem; there are plenty of development boards that implement what I'd call "thoughtful" design.

For example, on the left is the mikroBUS form factor. You can see that although the headers are symmetrical, even if you accidentally rotate the board being plugged into the socket, there is no real danger of reverse polarity since the power sources will instead be plugged into the reset and interrupt pin sockets.

This is thoughtful design and can help save users wasting their precious time from worrying and double checking over and over if they are plugging in their boards correctly. So instead of putting the 5v and the 3v3 at the opposite end of the header pin rows, placing it just beside GND will make things a bit safer.

Another way to prevent accidental reverse polarity situations is to have asymmetrical headers, like what the Arduino or the featherwings have. That way, it becomes much more obvious when something is being plugged in the wrong way around. Although this doesn't completely remove the possibility, the fact that it becomes easy to inspect if something is plugged wrong makes checking faster and easier.

Missing Breakouts for Important GPIO

We've mentioned how the PAN1780 manages to shrink the nRF52840DK's footprint by dropping many of the GPIO breakouts, and those GPIO that have been dropped were good choices. However, there are a few GPIO that I wish they had broken out since they are quite important to some of nRF52840's functionality.

The biggest of this omissions that I feel should have been there was GPIO 23. GPIO pins 17 19 20 21 and 22 are broken out, and these are the pins that are connected to the QSPI Flash in the nRF52840DK. That means that, had GPIO 23 been broken out, a QSPI flash would have been easily attached and the example hex binary in the nRF52 SDK would have worked without any modifications (which simplifies the work of a someone who just wants to prototype something).

Those QSPI Flash examples were quite cool too; one of them allows the nRF52840 to emulate a file system, allowing you to simulate a flash drive for example.

I also can't confirm it right now, but I don't see any low frequency crystal in the schematic and documentation; however GPIO pins 0.00 and 0.01 aren't broken out. If it's really the case that there is not low frequency crystal onboard, omitting 0.00 and 0.01 means there is no way to prototype applications and projects that rely on precise timing in the 32khz range (the module still works fine with the built-in high frequency crystal but the low frequency oscillation will be emulated). Update: looking at the block diagram, the PAN1780 seems to have the low frequency oscillator built-in.

Second USB Port (X5) does not Provide Power

I've had many planed projects shelved because of this. I'll talk more about those in the section Boulevard of Broken Dreams, but I am still quite surprised why the Micro USB port that's connected to the D+ and D- lines of the nRF52840 don't supply power to the board.

It would have been fine (albeit inconvenient) if the D+ and D- were exposed as separate pins or header sockets, but placing them in a Micro USB port while not being able to supply power belies expectations. You wouldn't think twice about being able to supply power to a USB port; that has been the experience since USB became popular, and designing the Eval Kit such that this port does not actually supply power makes the user second guess themselves.

Is my power bank dead? Was my USB cable bad? Maybe I'm not supplying enough voltage or current? Or is the power supply ripple too much? Did I just kill the board?

These were the many worries I had when I plugged in a Micro USB cable expecting the board to power up. It took some time with the schematic and a multimeter (because this was not mentioned at all in the documentation) and a few questions to the road test page (thanks jeff_electron for all your clarifications!) to confirm that indeed that port does not supply power.

Maybe the electrical routing in the circuit makes it difficult to route 5v to the board with the presence of the other Micro USB port, or Panasonic Industry was worried that users will plug in two Micro USB cables at the same time and accidentally fry the board. In that case, making a mention of this in the documentation and having an application note on how to actually use this X5 port would help tremendously.

The Ugly

There are also a few gotchas that range from "inconvenient" to "questionable" that warrant mentioning. While not as grave as the items presented in the Ugly section, I feel they still merit some consideration. They won't necessarily make or break the decision to get the PAN1780 Eval Kit, but you can feel the good intentions behind them; it just needs a few tweaks to take them over the line

Not Enough Readily Available Ground Pins

One of the project ideas I wanted to try was to compare the current consumption of the PAN1780 against various other development boards, with just the chip itself (via JP9 for example) as well as including all onboard peripherals. I also wanted to try out characterizing the regulators present, as well as look at some waveforms and signal communication between the module and the various other devices on the board.

Unfortunately, I had a difficult time finding a near-enough ground point that I can use so I can minimize stray inductance from having the ground pin so far away.

From what I could find, there's only a few available ground pins: the two near the NFC antenna pins GPIO 9 and 10 (which would be unusable if the antenna is attached), two near the bottom of the row headers, and one near JP9 (where you're supposed to do current measurements).

Contrast that to the nRF52840DK which has whole rows of ground just beside each exposed GPIO pin, as well as some generous test pads connected to ground reference.

Non-standard Header Layout

Even though the PAN1780 Eval Kit has male pin headers at the bottom, it is not breadboard friendly. You'd need at least two breadboards abreast each other and have the board straddle between the power rails.

So while this is workable, it's not very convenient for quick circuits and equipment tests since the breadboard would be taking double the space.

That means that in order to prototype circuits with the board, you'd need to either create a carrier board that would bring out the bottom pins so they are connectable from the top (instead of from the bottom) or you can make a sort of shield system that goes on top of the board.

While the spacing of the pins are in the typical 0.1in grid (which makes using cheaply available protoboards very easy) I have yet to find a standard that is compatible with these GPIO rows.

I had a few Arduino compatible shields lying around, and in order to prototype with it I had to create an adapter board that maps the PAN1780 pins to the Arduino pins.

While it was straightforward, I can also slightly understand why the Arduino form factor is not a good choice: since Arduino had mostly been driven by 5v power, many shields draw from the 5v supply pin. This would then also mean that the logic level for the peripherals on board the shield would also be in the 5v level. Since the nRF52840 in the PAN1780 eval kit operates on 3v3 it can be dangerous to send 5v without any logic level conversion; which would likely increase the cost of the kit.

So while the Arduino form factor may have too many drawbacks that make it a no-go, I wish Panasonic Industry could have at least considered various other "standards" in order to take advantage of their corresponding ecosystems. This is after all, an evaluation kit and one of the things it should support is the rapid integration of test peripherals to immediately ascertain the suitability of the module. If every circuit needed a custom PCB or wiring, that would likely defeat the purpose of quickly iterating through designs.

Some other examples of connector "standards" (in quotes because they're not actually standards but more like conventions),

• mikroBUS by MikroElektronika
• Feather Specification by Adafruit
• Pmod™ by Digilent
• raspberrypi hats by Raspberry Pi

Male Pins at the Bottom

As mentioned previously, The PAN1780 isn't breadboard friendly even though it has male pins at the bottom. I found that this is somewhat problematic, because of how it makes the board unstable.

It might be best if the board just didn't have male pins at the bottom especially since it isn't breadboard friendly anyway. That way, the base of the board lies flat and it becomes easier to work with (and becomes, in a way similar to how you would work with an Arduino UNO).

In my case, I had to make my own baseboard just to make sure the board stays level whenever I am working with it, as well as to protect against accidental short circuits.

I feel that there was the intention of giving flexibility to the board design (by maybe allowing the board to plug into a base circuit) but the lack of pre-made base boards available for sale make it more of a constraint.

Inconsistent / Confusing Silkscreen

Maybe it's just me, but I found it really difficult to match the schematic to the actual board layout.

It started out with me trying to figure out how to enable high voltage mode on the nRF52840. The schematic clearly labels JP9 and how the circuit is connected, but it was quite confusing how the actual board matches up to the schematic.

I had to bring out my multimeter to do continuity testing on some of the pins, and I think I've got how the board's layout is supposed to match the schematic: if the schematic is right side up, the board must be upside down. That way, the pins as labeled on the schematic matches the way the pins are laid out on the board.

For example, on the right is the same JP9 I was interested in. I didn't know which pins were which (even though I know there are three pins, and that one of them was GND). If I rotate the board like this and read the schematic, the three pins 1 2 and 3 match the board pins from top to bottom.

While it's good that the pins' layout for many of these breakouts match the same order as they were laid out in the schematic, the silkscreen being "upside down" relative to the schematic threw me out in a loop.

What makes it worse is that the schematic provided is an image so its elements do not respond to a text search. Looking for a net becomes an ordeal of tracking every line, zooming in and out, and second guessing oneself, just to confirm that VUSB for the X5 Micro USB port is only connected to a pin on the chip and does not provide power (or does it? -- as we've seen in the Ugly section above, sadly it doesn't).

I think the one of the easier fixes for this would be to do what the Nordic nRF52840DK does: mark pin 1 with a small dot so there is no question about the orientation. For example, here on the left I marked with arrows some various connectors that were marked with that dot.

That way, even if the board layout would differ from the schematic (for example to preserve a schematic convention of having the power sources at the top and ground at the bottom).

Alternatively, "rotating" the silkscreen so that the pins are at the same orientation as the schematic would help navigating the circuit. That way, the numbered pins would match the how pins are laid out on the board.

Another solution would be to allow text searching of the schematic. The documentation is in PDF format anyway; there should be a way to change all the labels into proper text that can be searched for.

Perhaps the best solution would simply be to provide downloadable CAD files that someone can then open in their favorite circuit design software and trace to their hearts content.

Difficult to use Documentation

Unfortunately, I faced other documentation issues aside from the schematic and the silkscreen mismatch.

One of the projects I was planning for this road test was getting Circuit / MicroPython flashed and eventually getting a TensorFlow demo running. I've done some prototypes for flashing Circuit / Micropython for the nRF52840 in another blog series I made looking at the ebyte bare chip.

In short, the nRF52840 is especially suited for Adafruit's UF2 bootloader (USB based) because of its native support for USB: just connect the wires straight to the respective pins, wire up and configure high voltage mode so you can power everything from USB 5v, and you don't even need any other external component (aside from an optional reset switch if you want to enter bootloader maintenance mode).

High voltage mode really makes everything so much more convenient, because it allows for easier sourcing of power (for example, you can connect the supply immediately through a LiPo or directly to VUSB without having to regulate it down to 3v3). So one of the things I wanted to try out was configuring the nRF52840's support for a wider range of voltages (from 1v8 to 5v5) in the PAN1780.

This was where I found the most frustration: while the schematics do say which things are connected to where, it can be very difficult to read.

For one thing, the schematic is an image so its elements do not respond to a text search. Looking for a net becomes an ordeal of tracking every line, zooming in and out, and second guessing oneself, just to confirm that VUSB is only connected to a pin on the chip and does not provide power (or does it?)

Another thing: some portions of the docs (most notably the jumper configuration section) can be ambiguous. Since we're dealing with power supply here, it's quite important to be clear on what and what not to do. They did this well on the warning with the 3v3 jumper that should not be connected if the board is being powered externally, but there is not such warning for the 5v IO jumpers (JP1), nor for  the VDDH connection with VCC (JP12).

For comparison, on the right is the power source switch from the nRF52840DK where it's clearly labeled and it's really easy to configure the power supply to be used. This is also mentioned and well documented in the nordicsemi infocenter; something that was lacking in the PAN1780 version.

One other difficulty was that the important information in the documentation is spread-out in multiple documents. The PAN1780 Evaluation Kit box did not contain any paper manuals nor cdroms(!) nor USB drives along with the box. It did however contain a paper slip printed with a QR code that, when scanned, leads to a gateway page asking you to choose between the North American Site and the European Site.

I then managed to find what I would consider to be the canonical information repository for the PAN1780. In that page would be what I would consider the "main" docs (which is the module integration guide) and various other material like marketing flyers, RoHS information, and some tiebacks to other Panasonic Industry products. Unfortunately, there doesn't seem to be any ranking of the documents, nor some kind of "read me first" indications for what should be considered important reading.

Case in point: this Application Note. When I first received the boards and was writing some notes for this review, I decided to go and finally read through it. Then I noticed this section:

I had already flashed a few things to the board to try out some ideas, so I checked if I have, indeed, "accidentally" erased the pre-programmed public Device Address.

PS C:\Users\tristan> nrfjprog.exe --memrd 0x10001080 --w 8 --n 6
0x10001080: FF FF FF FF FF FF 

Looks like I've cleared the public address. Ooops.

The other board was untouched and still had the information on it.

PS C:\Users\tristan> nrfjprog.exe --memrd 0x10001080 --w 8 --n 6
0x10001080: 91 9C 1D 7E FE EC                                 |...~..| 

There doesn't seem to be any harm done even after having erased the device address, and the application note does say I can still retrieve the original pre-programmed public device address from the bar code printed on the metal shell of the module, so not all is lost. Still, it would have been better if these important notes were mentioned upfront in documentation arriving alongside the product. There might be even more of these "beware of accidental" notes that I've already done, but not yet aware of because I haven't gone through all of the reading material.

Lack of Community Support

The presence of a community surrounding a chip can be a great great advantage. The ATmega328 for example is well known to almost anyone who had at least dabbled in electronics, due to its use in the Arduino ecosystem. Atmel (now Micron) benefits from this and now has many of their other chips like the SAMD21 integrated into various other Arduino and Arduino-compatible boards (like for example the Seeed Xiao).

Raytac gets additional sales (and mindshare) of its modules from Adafruit (see for example https://www.adafruit.com/product/4078 ) and gets their modules out into the field and tested by thousands of people by virtue of being integrated with a number of Adafruit's products. The same goes with Espruino and their nRF52832 breakout boards (see for example https://www.espruino.com/MDBT42Q ). There's a large community surrounding these products, and indirectly Raytac's products.

The new Arduino Nano 33 BLE and BLE Sense also uses an nRF52840 module in the form of the u-blox NINA b306. While not as large as their AVR siblings, there is still a substantial mindshare on the products, due to them being official Arduino boards.

The PAN1780 (possibly being a new chip) however does not have these kinds of third party communities around it, and it had been difficult to find online forums and posts that talk about it. Element14 Road Tests do help, but one possible way to jump start communities would be trying to sponsor firmware development like what Nordic does with the Thingy:52 on Espruino. They would not only help expand the reach of their products, but they would also be cultivating the growth of open source (and later on, the amount of people directly working on their modules).

Speaking of forums, the one managed by Panasonic Industry seems to be dead. I tried checking the level of community support by posting my high voltage question in their forums but it's been over a month now and there are hardly any views, let alone any answers to my question.

There's even this person Amar who had a question on Bluetooth Low Energy, who came back just to answer himself after a few months in between.

Contrast that for example to the bustling activity in the Adafruit and Espruino forums, where fellow users would be answering each other's questions not only with the general product but also with regard to the specific modules that go into making that product.

Boulevard of Broken Dreams

When I applied for the roadtest, part of the projects I wanted to try out was getting Espruino, Micropython, TinyGo, and Arduino as base firmware to write programs on. Unfortunately, due to the X5 USB port not providing power and my own lack of knowledge in reading schematics (aside from the fact that there is no mention on how to properly use the X5 port in the manual) I wasn't able to proceed.

After some thought, I decided that instead of going with the other language firmware, I would double down on the firmware language I already knew was working and focus my efforts there.

I was quite happy with the result though, because I wasn't planning on doing Web Bluetooth in the beginning. I thought that since I was already doing javascript on the bluetooth microcontroller anyway, I might as well try and learn the corresponding apis in the browser. It also gave me more confidence in doing the actual roadtest, as I knew I could exercise the eval kit much more thoroughly and not spread myself too thin by trying out too many experimental firmware.

I still do plan on eventually learning and getting those language firmware up on the nRF52840; they just wouldn't make their appearance on this roadtest.

Speaking of roadtests and Espruino, did you know that Espruino had its own roadtest in element14? It was just a shame that the event recording was somehow corrupted; it would have been nice to be able to view how it was back then.

That time it was only able to run on an STM32F103 but now it has ports for the ESP8266, ESP32, as well as the nRF52832 and the nRF52840.

Coming from a software development background, I felt immediately productive doing microcontroller programming with Espruino and only had to do very few mental gymnastics to transfer my software development skills and map them onto hardware.

In the span of a few years, Espruino has grown by leaps and bounds and has been picking up interest especially in the smartwatch area. Come to think of it, the PAN1780 module itself is small enough to be fit inside a smartwatch--maybe that's an idea Panasonic Industry would like to support?

I also had this idea of doing a wireless ammeter inspired by shabaz's blogpost on current measurement. In my case, it would be using an INA219 instead of the INA210/214 as mentioned in the blogpost as it was more readily available in breakout board form.

I also wanted that experiment to highlight the advantages of using a more widely-available form factor (in this case the Arduino Uno R3), so I made an adapter that maps the PAN1780's header layout to that of the Uno. I then used a commonly available datalogging shield to jump start the sensor and peripheral connections (the shield would already have sdcard through SPI support, as well as a real time clock--with battery backup--through I2C) and populated the prototyping area for the actual ammeter and display circuitry.

While I've been able to get the INA219 measurements up and running, I didn't have time to do the Web Bluetooth dashboard, nor implement any kind of use for the sdcard (I wanted it to also do datalogging for measurements that need to span for hours). I also needed to reserve time for writing up the actual roadtest review, and all I had were notes and scarcely any pictures of the build (I usually take pictures after the fact).

It won't be in this review, but I plan on updating this with a link to the finished project once I get around to getting that done.

Final Thoughts

Evaluation boards are usually intended to help an engineer or designer assess the capabilities of the chip or module under test, and help them decide whether it would be worth designing a final product based on that chip.

While I personally am familiar about the capabilities of the nRF52840 (having tried out some projects with the Nordic Development Kit, as well as experiments on bare chips) I found that the PAN1780 Eval Kit lacks some necessary hardware and peripherals to present the nRF52840 in the best possible light.

That, and the lack of support and documentation specific to this module makes it quite difficult for me to recommend to another hobbyist (the perspective I chose when I initially applied for the roadtest). Maybe in the future the support and documentation will be improved, and there will be a V2 of the eval kit that addresses some of the major issues I've found.

Which is really a bummer, because the nRF52840 by Nordic is such a powerful chip that it's would be a waste if an evaluation board is not able to bring out its maximum performance and capabilities. As we've seen in the past projects, the chip is powerful enough (and has the memory to spare) to run even interpreted languages such as Javascript and MicroPython; imagine what can be done with a tightly tuned firmware.

If you're a hobbyist looking for a development board that already has integrated sensors (or you simply wish not to integrate your own) you might be best served by the Adafruit Clue, which is also programmable via CircuitPython out of the box.

You would forgo much of the flexibility afforded by the other development kits mentioned above, but you do get in return a compact and robust circuit that you can even embed in a project. You can even get away without any soldering via the QWIIC and Stemma QT connector; that kind of connectivity comes at a cost though since you would need your peripherals to also support such connector standard.

The Waveshare evaluation board is right smack in the middle with a smattering of built-in peripherals, but still retaining the flexibility that befits a development board. It even a Raspberry Pi compatible pin layout which allows it to easily integrate with various HATs and breakout boards made for the pi.

It's also the cheapest of the bunch; although the likely reason for that is it forgoes the built-on programmer and you would have to buy your own.

Then again, a JLink EDU MiniJLink EDU Mini isn't that expensive, and once you "graduate" from development boards into designing your own circuits with just the bare module, you'd definitely need one of those standalone programmers anyway so it's a good investment.

If you are already working with the nRF52840 and already know about its capabilities, or you're looking to migrate from one of Panasonic Industry's prior bluetooth modules for an existing product (which most likely does NOT make use of and won't benefit from the extra capabilities of the PAN1780, aside from improved power tx and range), then you might want to consider the PAN1780 Eval Kit (or its two-pack versionits two-pack version).

It is a good secondary development board that is convenient and portable, much like how you would have something like an Aneng AN8008 as a backup DMM with your Fluke or Agilent multimeter as your primary tester.

Compared with the nRF52840DK, having a smaller amount of GPIO broken out might be a blessing as the sheer amount of options available to you with the Nordic devkit may be overwhelming when all you needed was a simple integration test with a new sensor.

However, if this is your first experience with the nRF52840, it's best if you get the Nordic nRF52840DKNordic nRF52840DK as that devkit is how Nordic envisions their module to be evaluated. It has all sorts of connectors and switches to for various capabilities, like power sources or the ability to isolate just the nRF chip for better current measurements.

The nRF52840DK has everything the PAN1780 eval kit has to offer, and then more. Probably the biggest benefit here is that all of the nRF SDK examples would work without recompilation, which aids in debugging since you would have a known "good" binary to confirm if you had a hardware problem or a software bug. So if you can afford it, get the nRF52840DK first and then the PAN1780 eval kit if you're looking to integrate their PAN1780 module in a design, or just looking for a full-featured dev board that's functionally the same as nRF52840DK but much smaller and portable.

And that's it for this roadtest! I'm curious to know what you all think, or if you have any questions, or is there anything I can improve / clarify.