• Finaly getting hardware and learned morea bout BLuetooth and andriod

    Hsingai Tigris Altaica • 10/26/2024 at 09:16 • 2 comments

    I got a T-deck for my PDA project and decided to get one with LoRa because, why not. Then I got a Heltec Lora32 v3 and Cardputer for Xmas last year.  

    I'm been busy trying to start my game studio so haven't had much time to work on it but the 2 years I'd given to starting it are finally up. 

    This year I'm getting a few of Circuit Digest's LiteWing drone to experiment with autonomous repositioning to improve the new work coverage and data ferrying.

    I found out just how slow LoRa is and how small the MTU is.  I know the numbers, but I don't realize the practical significance of them

    We attached a finder to the remote we keep losing, it wasn't a bluebooth one but it got me interest in those Bluetooth beacons like the Airtags.

    So I learned some about Bluetooth to find out if you could make your own app for them.

    So looking into it, It shouldn't be that hard to make scatternet out of Bluetooth/WiFi the device would operate as WiFi AP/Bluetooth Peripheral and when a node wants to send data to it, it connects.

    This means it would be point to point and not broadcast like I wanted but with the higher data rates it should be a problem.  

    I'm not sure about how Ergonomic it'd be. I think on android the user just needs to accept the connection once then it will allow it to connect to the device again. but I'm not sure.  

    Even it is a PITA, it would still allow you to connect to the network with an ordinary phone.

    and it should be work perfectly on Linux computers and nRF52, ESP32s.

    on the protocol front I was thinking of the network make a Minimum Spanning Tree to give nodes a topological coordinate but then I heard about Minimum Diameter Spanning Trees and realized that what I really wanted. 

    We can use the Spanning Tree to reach any node from any node, now I'm looking into ways to find better paths between nodes

    Right now, I'm thinking about each node keeping track of all the nodes that it can reach by 2 disjoined paths

    I'm also considering some sort of hierarchical clustering-based routing.

  • some thoughts on routing

    Hsingai Tigris Altaica • 09/03/2023 at 13:45 • 0 comments

    I never got a Lora or EPS32 board to develop on but I want to get one of the the new T-Decks to program as a PDA to remind me to take my meds and it has a LoRa module. So I'm looking into Wakan again. tough I don't has a much free time as I use to.

    Anyways Wakan nodes don't keep track of how to route messages TO other nodes. they keep track of how to route messages FROM other nodes to them. I'm calling them 'etuor' ('route' backwards)

    lets call the nodes in the nodes in a nodes's Etuoring table it's acquaintance nodes.

    When a node(A) receive a message from node(B) going to a destination(C) it will find the node(D) on the message's route closest to the destination(C) that it knows about then remove itself(A) and all nodes farther from destination(C) from the messages route then do it's check if it should rebroadcast the message going from B for D and if so broadcast it.

    the other thing I was thinking of was:

    when trying to find a node that isn't in it's etuoring table it should find the closes and farthest(in the kadmilla sense) and send messages to them asking if they know,

    This is based on the 6 degrees of separation and the reason the farthest and closest is to avoid local minima

    and if they don't know they do the same. 

    This leap frogs the routeing list as the intermediate nodes aren't add just the ones ones. 

    of course if it doesn't know it just add the node it was asked to look up to it's list of nodes it's trying to find, and if it is already trying to find it just as the asking to the list one node it should notify when it finds out.


    of course this all assumes that nodes can store messages for much long than the time it takes for the update to happen.

    lets call the your acquaintance node that is farthest from you your far node. 

    Let's  call the your acquaintance node that is farthest from your far node your counter node.

    maybe we could do something with building paths from your far node's far node's far node's....

    of course you don't really want your far node of your far node you want the acquaintance from of your far node that is farthest from you.

    maybe something keep track of the nodes you know of that are farthest apart from each other, lets call them 'The Ends of The World'

    There is  an Upper End of the World which is The End of The World with the highest id and a 'Lower End of the World'

     with the lowest id.

    Let your 'Upper frontier' be your acquaintance node that is closest to the Upper End of The World.

    Like wise with your 'Lower frontier'

    maybe keep track of your Upper Frontier's Upper Frontier's... and like wise with your Lower Frontier


     these should be agreed upon globally, so if you can track of route to them it should be light on transmission over head for the network and of worst the  diameter of the network in storage.

    do to the triangle inequality the new end should be close to the old end

    The rate of the heartbeats The Ends of the World send out should be able to be quite slow as they are just used to optimize routing not a vital part of it.

    if a end dies then you try  to form a connection to the know you think is farthest. any node in the path can respond with a node it knows is farther. and the news of the know death is going to travel from the nodes netographically closest to the dead End of the World so it should find the new end then flood that information to the network before to many inquires about who the new End of The World is get sent.

  • Why it's called 'Wakan'

    Hsingai Tigris Altaica • 04/05/2022 at 01:47 • 0 comments

    I found the original Logo on a old harddrive. I has one of the Chinese characters wrong.

    Wakan comes from the etymology of the word 'Japan' one theory is that it comes from 和寛 which in the dialect of the time/place sounded like Wakan.  

    和寛 in turns comes from the ferries used to reach Japan.

    I liked the imagery of your  the underlay networks being islands and the overlay network as ferries taking  the data between them.

    I don't have Photoshop installed and when Krita it din't come thru as text layers.. I don't know if the text was prerendered in the PSD. so I recreated it in Krita

  • Who needs sleep?

    Hsingai Tigris Altaica • 04/04/2022 at 14:39 • 0 comments 

    func passthruKa(R, A, B){
    if (I know of a shorter route from A to B than the route that passes thru R){
        return(False)
    else {
        return(True)
    }
}

     The difference between passthruKa and RelayKa is that if you don't know of any routes from A to B RelayKa will return True while passthruKa will return False.

    when tracing route the stations will broadcast the Trace messages if they  passthruKa them.

    when (station_A hears a ChartRoute message from station_B) then {
    if (ChartRoute isn't in station_A["recent_message_list"]) then {
       if RelayKa(station_A, station_B, Chart_Route["GOAL"]) then {
            if (ChartRoute["PATH"] is empty) then {
                broadcast Trace(PATH : [station_B])
            } else {
                broadcast Trace(PATH: [...ChartRoute["PATH"], station_B])
            }
            append station_B to the end of ChartRoute["PATH"]
            broadcast the modified ChartRoute
        }
    }
}
    when(station_A hears a Trace from station_B) then {
    if (Trace isn't in station_A["recent_message_list"]) then {
        if passthruKa(station_A, station_B, Trace["PATH"][]) then {
            rebroadcast Trace
        }
    }
}
    when (station_A hears a PingRoute message from station_B) then {
    if (station_A == PingRoute["ROUTE"][0]) then {
        add Ack(ORIGIN: station_B, FOUNT: PingRoute["ROUTE"][0]) to station_A["recent_message_list"]
        pop PingRoute["ROUTE"][0]
        broadcast modified PingRoute 
    } else if (station_A != PingRoute["ROUTE"][0]) then {
        broadcast Ack(ORIGIN: station_B, FOUNT: PingRoute["ORIGIN"])
}
    when(station_A hears a Ack from station_B) then {
    if (Ack isn't in station_A["recent_message_list"]) then {
        if passthruKa(station_A, station_B, Ack["FOUNT"]) then {
            rebroadcast Ack
        }
    }
}

  • Random Notes

    Hsingai Tigris Altaica • 04/04/2022 at 10:42 • 0 comments

    I was learning how to do a P2P for my game and came up with something for Wakan....

    The stations find paths to the stations that they can hear in ReturnFlows.

    That keep track of all stations that they are in ReturnFlows with.

    The information that stations keep track of about other stations is what stations those stations can hear.

    Each station send a Heartbeat with a list of stations it can hear and stations looking for a ReturnFlow.

    Each station tries to find a ReturnFlow to the stations it hears with a RFLooking message.

    When a station hears a RFLooking message for itself it broadcasts a RFChain message with the found ReturnFlow.

    The station in the ReturnFlow reboadcast the RFChain message and update their routing tables 

    If I know another station that <B> can hear will send the information I don't have too.

    • If station I know, <B>, can receive the information I information I don't have to send it?
    •  Calculate the flow out form the <END>?
    when (station_A hears a Heartbeat message from station_B) {
    if (station_A doesn't have a ReturnFlow to station_B) then { 
        station_A broadcasts the message RFlooking(END:station_B, PATH:[station_A])
    }
}


    when (station_A receives a RFLooking and (RFLooking["END"] == station_A)) then {
    station_A broadcasts RFChain(CHAIN:[...RFLooking["PATH"], station_A])
}
    If (station_A recieves a RFLooking from station_B) then {
    if RelayKa(station_A, station_B, RFLooking["END"])then {
        add station_A to the end of RFLooking["PATH"]
        broadcast the modified RFLooking
    }
}

    If (station_A hears a RFChain from station_B then {
    if (RFChain isn't in station_A["recent_message_list"])
        if (station_A in RFChain["CHAIN"]) then {
            add RFChain["CHAIN"] to station_A's routing_table
            rebroadcast the RFChain
            var downstream = []
            var upsteam =[]
            for node in RFChain["CHAIN"] {
                if RelayKa(station_A, station_B, node){
                    downsteam.append(node)
                else {
                    upsteam.append(node)
                }
            }
            var routes = {}
            for station_X in upstream {
                  routes[station_x]["can_hear"] = station_A['routing_table'][station_x]["can_hear"]
            }
            broadcast Hearsay(ROUTES: routes)
        }
    }
}
when (you receive a Hearsay or a Heartbeat message) then {
    compare the reported can_hear's to your current routing_table and keep track of the added or removed links.
    var routes = {}
    for changed link from station_A to station_B  {
        if (you are in the shortest path from station_B to station_A in your routing_table) then {
            routes[station_A]["can_hear"] =Hearsay[station_A]["can_hear"]
            routes[station_B]["can_hear"] =Hearsay[station_B]["can_hear"]
        }
    }
    broadcast Hearsay(ROUTES: routes)
}

    Functions

    func RelayKa(station_R, station_A, station_B) {
    If (I don't know of a shorter route from station_A to station_B than the route that goes thru station_R. then {
       return (True)
    else {
        return (False)
   }
}

    Glossary

    'ReturnFlow': The quince of hops needed for a message to get from station <A> to some station <B> which station <A> can hear.

    'RFLooking': Has two parameters: END, The station we are looking for a ReturnFlow to, and PATH, a list of stations this message has past thru. Can assume that the last station on the list is the broadcaster(or that the broadcaster is the last station on the list?)

    'broadcast': an undirected transmission of a message to unknown recipients.

    'hear': the reception of a broadcast

    'send': transmission of a message to specific recipient.

  • puting uDTN on back bunner

    Hsingai Tigris Altaica • 04/06/2021 at 18:25 • 0 comments

    First the good new I found the original logo files.  Not vary helpful as I already recreated it but better than nothing.

    I was unable to get the LoRa development hardware.... My stepfather said he would get it as a present for me but never followed though.  My efforts on the the software simulation died to without the hope of getting real hardware. I'm not that interested in a purely academic thought exercise .

    I'm putting all my resources into my Opwned Source culture project, trying to make the world a better place by making it so they aren't fixed on satisfying their lowest needs on Maslow's Hierarchy of Needs so they have the energy to work on the good of the world.

  • Research

    Hsingai Tigris Altaica • 05/18/2020 at 17:30 • 0 comments

    I was inspired by the Armachat Doomsday Communicator to look restart my Wakan uDTN project  The goal is to support text and push to talk near real time voice (using codec2) messaging on a DTN of 200k nodes. the idea is to support a people tracking service to deal with the Missing persons issue facing indigenous communities.  Eventually I want to develop a $30-$60 cellphone replacement with full PIM features like the PalmPilot. 

    So far I'm found RF Mesh Network, This paper on Ripple, B.A.T.M.A.N.,  Bundle Protocol v7, PainlessMesh, and The Serval Project.

    I'm still waiting on my lora dev boards so an starting on a network simulator. I'm decided to use OMNeT++.  I'm trying to get a hold on the Open Source B.A.T.M.A.N. V OMNet++ simulation mentioned in Performance Evaluation and Optimization of B.A.T.M.A.N. V Routing for Aerial and Ground-based Mobile Ad-hoc Networks. I'll start with FLoRA  framework once I get done with the OMNeT++ tutorials.