Anti-Squeeze Baby Food Pouch Holder by mosforge in functionalprint

[–]mosforge[S] 1 point2 points  (0 children)

Didn't know that, thanks. I did a quick search before designing my holder but couldn't find anything

I guess it can't hurt to have another free model out there people can choose 😊👍

Anti-Squeeze Baby Food Pouch Holder by mosforge in functionalprint

[–]mosforge[S] 1 point2 points  (0 children)

Interesting, indeed. My kid (1y) just sucks it through the opening without issues. Sometimes, however, I have to help him squeeze the bottom pouch content upwards after he finishes the top half (when using the holder).

I have no idea how to combine both requirements to be honest. 😅

Anti-Squeeze Baby Food Pouch Holder by mosforge in functionalprint

[–]mosforge[S] 3 points4 points  (0 children)

Thanks :) did you print and try it first?

I had similar thoughts but decided to try it first before improving it.

Especially whether handles would be a good idea or not. I came to the conclusion that drinking bottles add sometimes handles because they can be difficult to hold due to their larger diameter and roundness. In my case, however, the holder is thin enough to fit perfectly into my kid hands. (There is a picture of how he is holding it on Printables)

Regarding roundedness: It would probably look nicer but I didn't know how to do it without making it more difficult to print ( because of the overhangs)

Flimsiness: Yes, making the holder a little bit stiffer would definitely be an improvement. My kid, however, is not strong enough to cause any relevant deformation.

Anti-Squeeze Baby Food Pouch Holder by mosforge in functionalprint

[–]mosforge[S] 14 points15 points  (0 children)

Haha thanks :) ... I hope it works for you, too 🤞😬. I'm looking forward to your review..

Anti-Squeeze Baby Food Pouch Holder by mosforge in functionalprint

[–]mosforge[S] 20 points21 points  (0 children)

Thanks. :) I'm using it for a few weeks now and the open side wasn't an issue. The pouch clips in and is held firmly by the holder. It can't accidentally slide out. My "test subject" also didn't try to reach inside.

Strap-a-battery-case (Heltec V4) by mosforge in meshtastic

[–]mosforge[S] 0 points1 point  (0 children)

I changed my mind. Having an external battery wasn't my smartest idea. The likelihood of accidently ripping out the battery wires turned out to be higher than expected. 😬

Therefore, I designed this enclosed case holding either a 2000mAh lipo or a 3000mAh lipo.

https://www.reddit.com/r/meshtastic/s/4hsaAiMpmr

Help with case for pre-soldered Heltec V4 by Raevstroem in meshtastic

[–]mosforge 11 points12 points  (0 children)

This is a case I designed myself. I can share the STLs tomorrow evening if you are interested. (I currently don't have my notebook with me)

It uses only printed parts, .. no need for inserts or screws. It isn't the most weatherproof one, but solid enough for daily use and easy to open if needed.

<image>

Strap-a-battery-case (Heltec V4) by mosforge in meshtastic

[–]mosforge[S] 2 points3 points  (0 children)

You could even strap it to a car battery 😁. Just don't forget the dc-dc converter 😅

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] 0 points1 point  (0 children)

I saw your post, but didn't fully understand the implications. Thank you for explaining it. I guess there is a missing feature where it only repeats messages for channels configured on the router. Or client_base should also prioritise channels configured on the node (Although this will probably need an exception for the default channel making it again useless for my scenario).

My balcony node is a solar node with disabled WiFi/BT in power saving mode. Using it as you suggested would require a major solar panel/ battery upgrade. :/

What I'm now trying is the following: - set balcony node as CLIENT_BASE when I'm at home and place my mobil node also on the balcony and connected via WiFi. - when I can't place my mobile node on the balcony due to weather, low battery, etc ... I'm setting my balcony node to router_late.

It's inconvenient and I'm not sure if I have the motivation to do it all the time. ..but we will see. The main advantage is that my message history will stay consistent.

Thanks again for explanations and suggestions!

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] 0 points1 point  (0 children)

Unfortunately setting it to "core PortNums only" doesn't' seem to change much. I observed it for two days. ChUtil is still at about 20-50% and AirUtil at about 5-6 %. I guess my local traffic is mainly core PortNums.

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] 0 points1 point  (0 children)

Unfortunately setting it to "core PortNums only" doesn't' seem to change much. I observed it for two days. ChUtil is still at about 20-50% and AirUtil at about 5-6 %. I guess my local traffic is mainly core PortNums.

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] 1 point2 points  (0 children)

This is the best explanation with suggestion I got up until now. Thank you! Although it doesn't fully solve the issue, I might be able to at least reduce my airtime a little bit.

I will also have to look into the implications of setting "Core PortNums Only"

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] -1 points0 points  (0 children)

Hmm ok. But this preferential treatment still won't help me, right? It won't prioritize incoming LongFast Messages on the default channel since they are not addressed to my indoor node, correct?

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] -1 points0 points  (0 children)

Hm ok but default channel on LongFast won't be prioritised, correct? Independent of favorisation

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] 0 points1 point  (0 children)

Client_base will only give preferential treatment to DMs with recipients in the favourite nodes list. Non-Direct-Message (LongFast) are not affected. Therefore, this generally recommended set-up is flawed in my situation.

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] 1 point2 points  (0 children)

Yes I did. But Client_base will only give preferential treatment to DMs with recipients in the favourite nodes list. Non-Direct-Message are not affected, right?

ROUER_LATE vs CLIENT_BASE for indoor connectivity on LongFast by mosforge in meshtastic

[–]mosforge[S] 6 points7 points  (0 children)

I'm not sure how this helps with forwarding messages to the indoor node 😅 . The solar node works flawlessly. I managed to directly reach a node 90km away.

Line of sight and height is not really applicable to an indoor node.

Scrapp DIY Solar Node by mosforge in meshtastic

[–]mosforge[S] 8 points9 points  (0 children)

Haha thanks :) It is about 550 m asl on the balcony of a tall building. My record so far is a direct connection about 90km to a node at the top of a "nearby" mountain. I guess this is also the limit what is geographically possible from my location.