Gps Module Working

0 views

Skip to first unread message

Griselda Humbarger

unread,

Aug 3, 2024, 4:20:13 PM8/3/24

to enswerbinkcran

I have been using the Radiomics module for several years now and it has worked properly. The latest version for which it still works for me is 5.4.0. In newer versions it does not work, the output is blank. I have not changed my computer platform so it is not a hardware issue. Is this a known issue, or is there something else locally I might need to address? Any help is appreciated!

Thanks @pieper! Managed to download and install version 5.0.3 from the link you gave. I also downloaded the radiomics extension for this version which seems to work perfect. will stick there until a new version of the plugin is released to work with the latest version of slicer

Hi guys, iam recently working with a project with arduino nano and which also includes a data logging for that iam using a very common micro sd card module for the arduino boards. When I started to work with it, first I just uploaded the cardinfo code from the example in the arduino ide and
it shows :
Initializing SD card...initialization failed. Things to check:

Iam pretty sure that the connections are correct, card also inserted correctly and I also tried both pin 4 and pin 10 for the chipselect and again tried from first and it again shows the same thing in serial monitor and i also checked a lot of times !! but the same results .

again I am pretty sure that wirings,card insertion are correct and I checked that more than thousand times !!!
but the result didn't change and in the next step I bought a new micro sd card and inserted that in my module but again the same result :
Initializing SD card...initialization failed. Things to check:

I have an SD card module here that looks pretty much exactly the same as the one you bought. One component might be in a slightly different place but apart from that it looks the same. These SD card adapter modules all work more or less the same.

I then downloaded v5.0.1 of the formatter from the SD Card Association (using your link minus the stray ')'!) and formatted a 2Gb SD card I had lying around.
After uploading the sketch, this is what I got:

I would suggest that you stick with pin 10 as the chip select for the SD card as that way, the SS pin is defined as an output. If you were to use another pin for your chip select, there is the possibility that if pin 10 were an input, that the SPI hardware would switch into SPI Slave mode.

Also, it was unclear to me that the language server was actually installed somewhere, so I used brew install hashicorp/tap/terraform-ls. and it now exists in /usr/local/bin/terraform-ls, as does the Terraform executable itself. So I rewrite the Terraform config in settings.json like this:

As for the language server - you should not need to install it yourself, we bundle the LS binary appropriate for your system (macOS) with the extension. If you remove the mentioned settings, it should default to the bundled binary, which can also be verified from the log.

We have made some changes in the (planned) 0.24.0 / preview, one of which is that we no longer rely on installed modules only, but use that only as additional source - e.g. when linking to docs of the installed module version (since we cannot link to a version constraint).

After troubleshooting, I found that changing my config.toml file from theme = ["github.com/onweru/compose"] to theme = "compose" got rid of this issue. However, another error started appearing: executing "index.html" at : error calling partial: partial "twemoji" not found

What I suspect is the culprit here is the mix of theme and module imports. I guess you could argue that it should work, but in my head you should use one or the other (I kept the theme option mostly for backwards compability).

I have a module that imports a crypto (crypto-js) library at the module level (3 dot menu > Scripts and style > Add new). When testing the module alone it works perfectly fine. When I include this module into an app it no longer works.

It doesn't reference any external info and all the data within the module is accessible. I know it has to do with the library because I'm using the crypto library to hash values and I can display the values I'm hashing just fine, but once I wrap it in the hash function it no longer work in the app (again, it works in the module though).

Is there some security setting preventing a module preloaded library from working in an app? When I add the library at the app level it doesn't work either though. Does it need to be added at the organization level? What else could be the issue here?

Thanks for the response @Pawan. I've tried that as well but unfortunately no luck there either. I wonder if there's also the opposite issue where the module doesn't have access to the app level imported library.

I have a function that hashes a value and returns it. When I check the value in the module (by sending to an Output), it returns the hash as expected. When I check the Output in the app it returns null because the crypto library used to hash is not available. If I edit the single line that's using the hash function from the crypto library to not hash, then I see the Output value in the app.

I went on ahead and did some of the leg work on my end and was able to get that library loaded into a module and the output of it be displayed in an app of mine. See the following screenshot of it working well:

I wanted to ask how you're importing this library in the first place? Also, how're you setting your output? Can you share a screenshot of where you loaded this library as well as a screenshot of you setting up your module's output?

I.e. custom css to extend width of dropdown for navigation in module, renders correctly.
Previewing said module works correctly.
Embedding module in a different app, width is not carried through.

One of the annoying details you'll have to content with is that the class names for elements in a module will not be the same when you're editing the module directly, compared to when they are imported into an app. When imported, the imported module name is prepended to the class name of the components contained within.

Another unfortunate detail is that the class names in edit and preview are not guaranteed to be identical . I ran into an issue where I was trying to style the primary nav icons to use custom graphics, I attempted to use an attribute selector [aria-label='foo'] to correctly match the item with the icon, but the aria-label's are not available in preview mode.

It seems like a reasonable ask to not pollute the global css with module specific styles, and those styles will be included into apps so the user isn't concerned with the importing app's configuration.

Hey guys,
We are using the particle-rf24 library with the nRF24L01+ modules (with PA and LNA onboard). A certain percentage of our boards will only transmit if you touch the RF module with your finger. We had this exact same problem on a different device without the Photon, and the problem turned out to have to do with the CE pin not being pulled high for long enough.

I'd listen to @Backpacker87 here. If RF performance on a board changes because of you touching a component that's a really good indication that there's either interference or other noise in the circuit. Proper shielding, grounding, and decoupling might help, but interference can come from many sources. However, in order to 'properly' troubleshoot an RF problem, especially if you have a PA and LNA in the design, you need to look at the signal at every stage and operating mode and observe the signal and measure noise.

That said, I looked at the datasheet and it looks like you drive CE high for TX? Do you know if the output driving CE has enough power to hold it high? If the driver is unstable you might see problems without a cap and adding one could maybe make it worse. You might need to pull the CE high using a resistor and then drive it low using your output, or use a driver circuit so that CE isn't held high just by the your output pin. Of course, I don't know your circuit so read up on pull-ups and maybe BJT drivers and figure out if that works for you before trying anything.

Ok so, floating as in not connected to the CE on the nRF???? (can't be, right?) or as in hanging off of the connection between the nRF and Atmega, I assume? I know you put it away already, but for completeness... the resistance in the second option should affect the impedance of CE connection. The impedance will impact the coupling of RF noise or signals onto the trace/wire connected to the CE pin, so it makes sense to me that this had an effect, but it's uncontrolled... A decoupling cap (at the right value) mounted close to the CE input should eliminate spurious signals in a more intentional way.

I have multiple uno based system that uses the NRF24L01+ module (has FCC cert) in a mesh configuration that supports 20 nodes + talking to a single base on a 2 second interval. Once you get them working they are pretty cool what they can handle including my favorite, which is the ability to assign channels on the fly.

Yes, the 0.1uF is a decoupling cap. Often an app note will recommend the value but I don't see one in the datasheet. It should be on the nRF CE pin side.
The uC pin should never be an input when you use it to drive the CE pin. That's pretty confusing to me.

Usually either a pull-up OR a decoupling cap on one pin. The pull-up stabilizes your HIGH supply so that the uC output pin doesn't have to send all of the energy. With a pull-up, you allow power to come from the supply and the pin just shunts to GND when you send it LOW, make sure the pull-up resistor is large enough that you don't shunt too much power (check datasheets). This fixes a situation where your pin lacks the power to drive the line, it does nothing for noise.

If the supply is noisy, like @Backpacker87 suggests, then it's not more power, it's a clean signal you need. The cap smooths the voltage, like a damper in a car's suspension, so that it doesn't bounce around. If you use them together you start to filter specific frequencies, a wire plus a cap is just a very low value resistor and a cap so it's works the same but you aren't building a filter so the resistor shouldn't go in-line.