Liquid Soulder

Member Since: May 25, 2018

Country: United States

Details of a silly problem with a silly solution: How to not overwrite your outgoing SPI data buffer when using the Arduino core libraries

Continue reading

  • Glad to hear it! You got everything working alright since yesterday?

  • 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)

  • 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:

    • Added status led
    • Removed battery charger ( allows connection of batteries up to 15V without modification of the board, for example sealed lead acid car battery. )
    • Put EEPROM on its own SPI port to support micropython

    I expect that these new models will be in stock some time next week.

  • 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!

  • 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.

    • A single byte stored in that file looks like 0xZZ,_ because it is in human-readable ASCII form. To get the pixel data (two bytes worth) actually takes 12 bytes from the SD card including the leading 0x’s, the commas, and the spaces before the next bytes.
    • Then you still need to send two bytes directly to the display

    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:

    1. Come up with your own file format that directly stores the bytes in binary, as opposed to encoding them as human-readable ASCII characters. This should get you to roughly 25 Hz (transmit 2 bytes from SD and 2 bytes to display for each pixel).
    2. Try reading from the SD card at the highest speed possible (approx 20-24 MHz) by switching the SPI settings each time (and back for the display of course)
    3. Try writing a compressed file format to transfer even fewer bytes from the SD card for each image. (This is only an improvement when the image is suitable for compression)

    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:

    • read up about the various video encoding methods that exist, particularly those that you have in mind for the project
    • keep only enough data in the controller’s memory to handle one frame at a time
    • try to minimize the work done by the brains to update the frame by only modifying pixels that change
    • update the entire screen with that frame buffer at the rate you’d like.

    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)

  • Thanks for the fix! I’ll update the link. - Oops looks like M-Short beat me to the draw at high noon

  • 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 :(