We are in contract renewal season. We are sticking to 0.2 MHz of satellite capacity, though the frequency and satellite in Europe may change. It’s possible we are going back to Astra 3B. There may be a minor lapse in service for customers in Europe. But that is pretty normal for this time of year.
The real point of importance is increasing the LoRa spreading factor once the new contracts are signed. I’m mildly confident that chips will come back in supply by this summer. I’m also targeting a $50 price point for a Dreamcatcher, so that should mean a nice influx of new Othernet users. Since there will be new users, I would like to make pointing and reception as easy as possible, based on the resources that are available. The only lever we really have is spreading factor, which allows the antenna to get smaller and further removes pointing requirements.
Ideally, I’d like an omnidirectional monopole antenna to receive the signal. So we would go from 13 dBi of gain from the current antenna to maybe 3 dBi of a quarter wave monopole; basically just the metal pin of an LNB, without the corrugated horn.
But why reduce the bitrate just for the novelty of making it easier to receive? There are some IoT (Internet of Things) use cases that could really drive sales and those sales could allow for more bandwidth/faster bitrates—and additional channels in new regions.
The bitrate would be laughably small—on the order of 200 bps. Not much faster than the original Bell 101 modem.
What would be the maximum net bitrate the SX1280 or better the new L1110 chip could digest? Omnidirectional and roughly pointed to a satellite, but always without a dish. Considering bandwidth was not a cost point… ?
I don’t know the PFD limits in that region, which will say how much power we can put in the channel. We can use a 1600 kHz channel and SF12, which should allow for reception by an omnidirectional antenna at a bitrate of 2 kbps. But if money is no object, we could increase the power in the channel, which would compensate for the low-SNR of the omni-antenna. My guess is that the best case scenario is 10 kbps, which is 100 MB of new content per day.
that would be cool so the bullseye would still work if I am understanding this right but a omi directional antenna would also become possible to work so then a lantern device would become very easy again and or a device that just gets tossed outside quickly then just works becomes possible.
I have a suggestion to make pointing the antenna easier:
First there should be default settings for the most common satellite signals so you just have to select the satellite. Idealy the Dreamcatchers could be pre-configured for the area they are beeing shipped to, so there is no need to look up the manual online.
Then I checked the azimuth, elevation and skew values for different cities here in Germany. There is a difference of around 11° maximum across the country. When you ship a Dreamcatcher to Germany, you could provide a small printed map divided into grids. Each grid would have the values for azimuth (magnetic), elevation and skew printed on them. So a user could tell the values for his current location without having to use the internet to look them up.
Then I made a device to point the LNB. You set the values for azimuth, elevation and skew. Then you place it on an even surface, align the compass with the marking and the LNB should be pointed perfectly.
The only thing left to do would be to power up the Dreamcatcher and you should be good to go.
Is the spreding factor increase and subsequent bandwidth reduction for the Americas too, or just Europe? 200bps means you would only get 17.28 megabits (2.16MB) per day, or 720 kilobits (90KB) per hour. That’s a super small amount of data. I know that the current 2.53 kbps isn’t completely used 24/7, but 200bps just seams too low. Is the compression ratio and FEC getting that good?
Also wouldn’t an LNB with a bigger horn have a similar result without needing to increase the spreding factor or transmission power as much? I know you would still need to point it, and have a high enough spreding factor, but you wouldn’t have to point it as accurately.
@Martin That’s a really clever little design. Can it be easily motorized?
@wvscout81 Yes, any increase/decrease in bitrate is held constant between the public channels. There are no changes to the compression of any content, so this would simply be a reduction in bitrate in exchange for ease of pointing/ease of reception.
Yes, increasing the aperture of the horn does increase the gain of that antenna, which improves the link budget and increases the SNR. All of that leads to higher bitrates, though makes it more challenging to point. Look at how much gain is possible with a 60cm dish–and look at what a nuisance it is to point! As the gain increases the beam width of the antenna decreases.
@Syed Actually this one is a simplified version of my motorized tracking device. But I am also planning to simplify my motorized tracker for the new Dreamcatcher when it will become available.
I assume you can eliminate your MCU and use the ESP32 on the Dreamcatcher. How many GPIO do you need to interface the motors and GPS with the Dreamcatcher? I can be sure to have those routed out and also connectorized.
I need 2 for serial for the GPS, 2 for i2c, 2 for the end switches used for calibration, and 12 to drive the stepper motors. But I guess I should be fine with 2 for serial and 2 for i2c when I use an external i2c GPIO expander. I could test that with one of my ESP32 before you change your design. Can you also tell me how much program storage space and memory would be available on the Dreamcatchers ESP32 for a script?
@Martin It looks like the version of Dreamcatcher without the RFFC5072 will barely have enough pins available for this. As of now, all of those pins have not been routed out, but I do not foresee that as a problem. However, there may be other things to consider.
The tracking system also requires power. What voltage do you need? And what is the peak current draw? In an ideal world, the user does not feed two separate power lines to the receiver (one for the Dreamcatcher and the other for the tracker).
Are you fine tuning the tracker’s position based on reported SNR? What type of data interface do you need from the Dreamcatcher? Are you using two or three motors?
The current version is powered by a 5V powerbank. And I did power the tracker and the Dreamcatcher with it. I don’t know how much current it draws, but I could check it. It shouldn’t be very much though. The Dreamcatcher was running stably while using the tracker.
I would like to have the reported SNR available. As for the interface, I am not sure. As I understand it the script for pointing would run on the Dreamcatcher and I would get the value for SNR directly from it? I have to say I am not an engineer and no expert with electronics, I just do this as a hobby and figure stuff out as I go along. I need 2 Pins for a serial connection for the GPS and 2 Pins for i2c for the magnetometer and the GPIO port expander.
I am using 3 stepper motors, one for each axis.
Breaking out an i2c bus to a header would be a good thing for any extension to the base design, so I’m all for it there are i2c GPS modules and stepper controllers as well
I don’t see a problem with routing out all available pins, as long as there is space on the board. But maybe the tracker makes more sense to be a self-contained device. I assume that a 50-cent MCU can handle the computational requirements of the tracker and a serial connection over the USB port should be sufficient for the SNR-values. The tracker could also power the Dreamcatcher.
no there currently is no way on DC3 or the new Dreamcatcher boards based on the ESP32, but i can add that. It would open a Serial port over USB and send the SNR (or maybe also RSSI) on Packet RX over the USBSerial.
We could also use a 4 wire connection with GND, +3v3, RX,TX as an alternative to connect to an external board.
there are i2c GPS modules and stepper controllers as well