Track My Order
Frequently Asked Questions
International Shipping Info
Mon-Fri, 9am to 12pm and
1pm to 5pm U.S. Mountain Time:
Chat With Us
May 25, 2018
Details of a silly problem with a silly solution: How to not overwrite your outgoing SPI data buffer when using the Arduino core libraries
Deskpionage with SparkX-level clearance
about 3 days ago
Glad to hear it! You got everything working alright since yesterday?
about 3 weeks ago
I never used “LoRa.setPins()” because I just redefined the default pins, however I looked in the library and you are correct about the order.
void LoRaClass::setPins(int ss, int reset, int dio0)
_ss = ss;
_reset = reset;
_dio0 = dio0;
I have a hunch that you need to call “LoRa.begin()” after “LoRa.setPins()” also.
FYI for the first version of this board (x01 in bottom copper layer) the pins should be:
- Chip Select (SS): 12
- Reset: 13
- INT: 6
(Those pin numbers may change a little for version x02)
about 2 months ago
You are correct, they are both based on the SX1276. I have sent packets between the two ( SparkX Pro RF and the SparkX SAMD21 Pro RF 1W ) however I did not use the RadioHead library. Rather I used the same arduino-LoRa library on both devices. The catch is that the pin definitions are different between the two so you’ll need to modify the code. The easiest way is to include LoRa.h directly in each sketch folder and change the #defined default pins. Here’s the schematic for the 32U4 ProRF so you can figure out which pins to define :D
If you need to use the RadioHead library it still should be possible, I just haven’t tested it. I say that because the LoRa modulation is standardized so once you have radio waves going out anything listening for LoRa should be able to get it.
Good luck and keep us posted!
Hi, I hope I can help answer some of your questions!
1. It is a micro USB connector
2. The best bet would be to use 4 AA batteries for 6V input. The reason is that the E19 RF module is designed to operate at 5V and the linear regulator onboard has about 1V dropout.
3. You can increase that number (500 kHz) to something more typical of SPI communication such as 1 MHz or possibly even 5 or 10 MHz. Just keep in mind that testing was done at 500 kHz so I am not sure what the upper limit is.
4. Yes, the u.FL connector on the E19 module should have the best RF output, but it will require you to either move that 0402 0-ohm resistor to the other position or try to close the gap with solder.
As a final note: stock of this item is running out. For the re-stock we have made some changes to address the problems with the very first release. The most significant changes are:
I expect that these new models will be in stock some time next week.
News - Hello, World!
about 2 months ago
Rob, cool to hear about your background in theatre! If you have a chance I’d love to talk about what kind of props or other work you created. Hope you like the new position!
about 2 months ago
From your other comment looks like you got this working. Nice going! That’s what I like to cal rubber-duck debugging. Hope you’re enjoying it
Good observations - the 50 Hz number comes from testing with data already in RAM. When you add in another interface to the mix there is bound to be some additional overhead.
Let’s assume that you access the display and the SD card at 8 MHz and that you store ASCII data on the SD card to represent the bitmaps, in exactly the format that we had used in the serial port example. Let’s keep track of how much data needs to travel across the SPI lines for a given pixel to update.
So to update a single pixel from the SD card you need to transfer 14 bytes as opposed to just two bytes directly from memory. That 7x reduction in speed leaves you with about 7 Hz, not to mention the time that your program needs to take to parse the incoming ASCII data. Accounting for the fact that there is probably additional overhead I’m not surprised to hear about a 2-3 Hz refresh time - I apologize if that was misleading in the first comment.
Let’s talk about optimizations:
Just as a curiosity pleaser for anyone reading this: you might wonder how real video monitors can refresh so quickly when this screen can’t. There are a lot of technologies that support this but two big ones are parallel ports and direct memory access. With a parallel port 8, 16, or maybe even 24 bits can be transferred in every clock cycle - leading to speeds closer to 240 Mbps (or 10 megapixels per second for a 24-bit deep screen). Direct memory access can allow direct communication between an external flash memory and the display or enable data transfer to occur in the background while the microcontroller performs other tasks.
Hmm, video streaming can be very resource intensive. Let’s also assume that you are using something with a little more oomph like a Teensy3.6 or a SAMD21 board. My strategy would be this:
That’s one of many ways to go about this, however there are many more!
We’re happy to help, but deciding on the specifics of your video protocol and writing code to convert other video formats is more than I can chew at the moment. Perhaps you could see if anyone else has written an open-source solution to this problem. If nobody has then its a great opportunity for you to do it! (If you do please share with me on GitHub and I’d probably take a peek)
about 3 months ago
Thanks for the fix! I’ll update the link. - Oops looks like M-Short beat me to the draw at high noon
News - Desk of an Engineer: the …
about 3 months ago
isn’t it surprising to see such a large part in cut tape? I’m also trying some FPC connectors that come in 50mm wide tapes. Thats the SMD Barrel Jack that I am putting on some exciting new IoT hardware for powering it in the field! Keep an eye on the new products list in the next couple of weeks and you’ll spot it.
No public wish lists :(
Forgot your password?
No account? Register one!