Murata type 1SJ modules

Hey
Has anyone been able to get any data sheets on the new Murata Type 1SJ modules ? I have the ludicrous situation where I actually have bought some modules from Digikey but can’t find any proper data sheets. The only thing that seems to be available is the flier.

I use the old type ABZ modules on a lot of devices but I am really keen to move to the new Semtech 1262.

I have tried asking Murata direct but just get the runaround.
Thanks

Guy

Manufacturer part number for this is LBAA0QB1SJ-something, 1SJ seems to be kind of shorthand like ABZ was in the SX1276 version.

I do really like the idea of the familiar STM32L072 + SX1262, may have to get a few and whip up a breakout board.

I’m not immediately seeing documentation of the internal connections between radio and MCU but that should be relatively straightforward to reverse engineer: with the PB12-PB15 which the ABZ used for internal SPI missing from the 1SJ package pinout, I very strongly suspect they used those again to talk to the radio.

That does leave the question of RF switch and TCXO control, probably the remaining DIO is connected somewhere so if not wanting to use polling for event completion it would probably take some code to search for it on the MCU.

Not yet seeing the EVK in stock or that would be interesting, too.

One thing that jumps out in the data sheet is that the power consumption does not look good: 15 - 20 mA while receiving, when the SX1262 should be 5-10 mA. There’s a note that says its with test firmware and the MCU is not asleep, but to get those numbers I have to wonder if they’re using the HSI/HSE (maybe they support USB?) and not the MSI clock that would probably make sense for such usage.

I also like how when they shrunk the footprint size vs. the ABZ, they did it by making the contacts smaller at 0.4 mm wide and keeping the spacing between the same or even larger yielding a more balanced 0.4mm land to 0.3 or 0.35 gap (varies by axis); the ABZ’s very imbalanced 0.5mm lands and 0.3 mm gaps tended to cause issues with manual protototyping.

Thanks for that, it has some good info but as you say there are still a few missing things, like the SX1262 connections etc.

I do have an evaluation kit on order which is due from DigiKey next month so hopefully that will answer the remaining questions.

Anyway, at least now I can get a test board under way.

The RX current will include an awake MCU and the SX1262 I guess.

Guy

I am just putting my first Type 1SJ dev boards together this week…

https://oshpark.com/shared_projects/seiOtR7h

Nice. Did you manage to get a Dev Kit and all the associated info on internal connections ?

Got the dev kit, haven’t had a chance to make use of it yet. But the Grasshopper 2.0 design is not dependent on this.

Anyone made any progress with the 1SJ modules?

I was able to get a couple of modules and dead bugged one to the point where I can run code and get serial output, question is if I do a brute force search of the stm32 I/O pins for the sx1262…

Yes. I bought the Dev Kit LBAA0QB1SJ-TEMP-EVK

It has an access code to all the documentation and a patch for the I-CUBE-LRWAN code from ST Micro / Semtech.

Unfortunately all the documentation is watermarked with the email address of the authorised recipient. It is very strange that Murata does not make their data sheets easily available.

Here is a PDF of the pin maps and comparison of both modules.

Murata Module Pin Maps.pdf (39.7 KB)

1 Like

Thanks, that’s a huge help, knowing which SPI and DIO etc signals are used should be enough to port code that already has this STM32 talking to this radio, to adapt to the way Murata interconnected them.

So odd, it’s like they don’t want to sell product, I’d have bought the EVK to get the docs (silly as that is for this project that’d not have been an issue), but it’s been persistently out of stock.

Murata radio’s are just not available, at least not in smaller quantities, with projected delivery for December for singles and Jan 2022 for trays with 1,000!

Guess I lucked out in getting a few from digikey last month. Was ordering for something else and though “this is pointless but let me check” and they had them.

Had to make a few code fixes, but it’s now working both transmit and receive, granted the RF situation with the module flipped upside down and a few wires soldered to pins isn’t great, but it’s enough to justify moving forward with supporting it as a (future) target.

You can get the dev kit from Mouser (everyone else seems to be on 0) - you just can’t get the current product, the CMWX1ZZABZ or the LBAA0QB1SJ-296 - I have 6 CMW left and have spent the last month reworking the main toolkits to be totally radio agnostic so I can mix & match with whatever I can get hold of for small batches. Which currently does not include any SAMDs.

Hi
I am wondering if anyone had success getting 1SJ module up and running? We had to do last minute applicaiton migration from ABZ module to 1SJ due to availability issues. Murata provide a patch (creates application for 1SJ) for ST’s I-CUBE-LRWAN 2.0.0 but ST have not issued I-CUBE-LRWAN 2.1.0 and apparently there is no way to download previous versions.

Using Murata’s patch, with 2.1.0 gives compiler errors. Working around them probably makes the application unable to run

There are a few people scattered around that have saved older versions because ST, as you observe, don’t allow you to download previous versions.

Check your private messages in a minute.

Hi Guy … I just took a chance too. I bought some 1SJ’s from Mouser who have stock but don’t they don’t have stock of the evaluation kit.

MuRata won’t let me even register to the LoRa 1SJ blogsite unless I have some registration number that comes with the evaluation kit … and … you can’t buy the kit (out of stock) …

Have you had any luck since? Having the design package offered with the evaluation package would sure be great … well I guess, I can’t see it to know. I found this in addition to items found on this group’s postings: [https://fccid.io/VPYLB1SJ](fcc filing)

I’ve never had this issue with a manufacturer. They always want to help me … help them ??

Peter

Hi Peter
Don’t feel too bad, we use type ABZ modules by the thousands and they still would not talk to me ! Very strange.

Anyway, I have a data sheet I can send you, check for PM.
I can probably package up a working instance of the STM32CubeExpansion_LRWAN_V1.3.1 demo code too.

There is a patch program that is provided with the dev kit that patches the STM STM32CubeExpansion_LRWAN_V1.3.1 code for this module. Basically it does the following:

  • Replaces mlm32l07x01.c and mlm32l07x01.h, sx1276.h with
    Drivers/BSP/Murata1SJ/murata1sjmodule.c
    Drivers/BSP/Components/sx126x/sx126x_board.h, sx1262x.c, sx1262x.h
  • in sx126x.c: commented out line 140 //SX126xAntSwOn( );
  • in hw_spi.c
    // Change to SPI2
    67 hspi.Instance = SPI2;
    105 __HAL_RCC_SPI2_FORCE_RESET();
    106 __HAL_RCC_SPI2_RELEASE_RESET();
    119 initStruct.Alternate= SPI2_AF ;
  • in main.c
    Removed LED commands
  • in mlm32l0xx_hw_conf.h
    changed all the RADIO pins to align with the new module (numerous changes)
    removed all the LED defines as the board does not have them
  • in mlm32l0xx_hw.c
    Removed the BSP_LED lines
2 Likes

I was able to get my 1SJ’s running via trivial changes to code I was using with a bare SX1262 based on the pinout table provided up thread.

I did have some yet unsolved issue where the first transmit wouldn’t quite work right, but all thereafter (even going into and out of low power) would.

Actual product level design would probably required getting the docs.

I ultimately bought two EVK’s, I noticed the registration code in both was exactly the same… The EVK’s are unimpressive, haven’t yet gotten the onboard SWD to work so had to bypass it with an external one. Probably again critical details hiding beyind the silly registration wall.

Why are companies run by such self-defeating idiots?

LOL! Two phrases “Dog food” & “Coal face”.

My first contract when I setup descartes was to develop an existing GP patient management system. I had to work with the customer user committee to fix things and the easiest way to understand what the problem was was to spend a few hours each week doing some work in a local users surgery so I got to know their pain.

Whilst I had to fix the bugs and implement the “all-new-exciting-features” that ‘management’ deemed important, we did reach a compromise where I got to fix & improve things based on the users needs & my own pain. Coal face user happiness scores went up because I was one for a short while and end user co-operation with me was good because they knew I “ate my own dog food”.

Continuing this policy over the years is probably how I’ve managed to survive so long.

If the vendors & creators of all the new shiny software & hardware had to spend a day a week using their offerings like we have to or need to, I’m sure the situation would improve.

But in the meanwhile, we’ll just have to carry on throwing sticks up at the windows of their ivory towers.

Thanks for posting your GrassHopper design. I’m designing a similar board with the 1SJ and uBlox MAX-M10S (GPS/GNSS). How does your PCB antennae perform and have you done any tuning or VNA profiling? My board was originally about the same size as yours but I’m being told (via simulations) that the ground plane is way too small resulting in about 15% efficiency.

Also Do you know if the 1SJ’s '072 variant supports DFU? (i.e., is the bootloader ID == 0x41) ?

Thanks and nice work!
-wade

I didn’t do any tuning, just adapted the reference design for the antenna. I did ask Johanson for some advice and they said the trace design was OK. But I know the ground plane is too small, and pi matching won’t help much with efficiency. The good news is that for many LoRaWAN applications even low efficiency is good enough. But we added the uFl as an option for people who wanted to do better. It is certainly convenient to have a chip antenna and not need an external antenna.

I don’t know much about the Type 1 SJ since we haven’t made much progress, being distracted with other things but since the MCU host is an STM32L072 I know it has an internal bootloader in ROM and that DFU should work. This is generally true of all STM32 MCUs.